"Experience, Empiricism, Excellence"
Please share with your colleagues and friends

The People View looks at the "soft-practices" involved in communication techniques, team building, decision making, leadership and team forming. 

We’ve spent much of our careers in software process improvement either at team, programme or enterprise level. Software process improvement is essentially Business Change in the software domain. Due to the need for a deep understanding of technology, complexity, workflow and various schools of thought such as architecture, testing, requirements etc. software process improvement is not a field well suited to traditional Business Change.

On the other hand, we’ve found that taking technically talented individuals and tasking them with improvement is often undermined due to their lack of Business Change experience and knowledge. To that end we value psychology based, technically grounded Business Change experts. Our accreditation programme reflects that, in that our partners cannot buy certification. They can’t go on a course and do an exam, we certify using behavioral interviewing over, focusing on experience and practicality.

Having been involved in the adoption of various processes and process improvement efforts we’ve observed a common negative pattern in software process change which we call the “process façade pattern”.

The process façade occurs when individuals, teams or organizations attempt to change their processes but the end result is that people use the new words for the old ways of working. In the days of RUP this pattern was called RINO (RUP in name only). Deeply dysfunctional Scrum adoptions are sometimes called “Scrumfall” as they use some of the language, and ceremony of Scrum, in waterfall processes.

We’ve seen many organizations who claim to be “doing agile” and yet actually act in the opposite spirit of the agile manifesto. In fact, this is so common it’s led to the publication of the “Half-Arsed Agile Manifesto”:

Individuals and interactions over processes and tools

and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation

as long as that software is comprehensively documented

Customer collaboration over contract negotiation

within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan

provided a detailed plan is in place to respond to the change, and it is followed precisely

That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.

http://www.halfarsedagilemanifesto.org/

Although there’s humor in these descriptions they represent a very real problem. That the philosophy and real meaning of software process change often doesn’t overcome the Homomorphic Force. Even if some of the language and ceremony is adopted at team level it is undermined by organizational inertia or resistance.

One of our clients claimed to have adopted agile methods (Scrum based) while still having a separate architecture practice exclusively following a waterfall V-model and a traditional waterfall Project Management function. This is just organizational denial, not change.

To overcome these problems, we believe a holistic (whole organization) approach to change and improvement is needed. Improving software process without considering portfolio, project management and governance doesn’t work. We need to ensure that the governance pressures reinforce the software changes, we also need to make sure that software changes do not damage the wider health of an organization.

We recommend that software process improvement is context specific, doesn’t try to force uniformity or synchronization and is based in evidence of improvement. A change should make a team healthier, cheaper, faster or happier – otherwise it should be reversed.

By implementing working feedback cycles, that don’t just report change but respond to changes at all levels of the business teams are empowered to experiment with improvements as the feedback mechanisms will correct them if something goes wrong.

Software Process Improvement is best served by accelerating Mastery in the people:

Individual Mastery refers to the continuous growth of a person's skills as well as the mechanisms useful in increasing and rewarding mastery.

 

As we learn more in a field of knowledge such as Software Development, Business Management or any of the various specialisms that those terms overlap with, we are on a journey from novice to mastery. As we learn more, we need to learn new things to keep our skills fresh. We need to learn from a variety of sources, some outside of our specialist field that inform our understanding at a deeper level.

Mastery = (knowledge + talent + practice) * experience

We can provide knowledge through training, reading material, discussion, workshops etc. We can’t change the talent people have but it is possible to supplement a workforce with extra talent, especially independent contractors with the required knowledge and skills to transfer to an in-house workforce. Only time offers experience although we can sometimes accelerate this with good coaching and mentoring

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn