A process is a set of steps that you can write down on a piece of paper. Waterfall is one such process(requirements, design, implementation, verification, maintenance). Agile is not a process, but a culture. People struggle with what a culture is but wikipedia has a great definition of Organizational Culture. Culture is more of the way the team looks at problems every day. We all want the ideal team that thinks outside the box, is willing to consider other ideas and embrace change. On a scale of 1-10, how much does your team embrace change and consider change? Most teams probably rank around a 5 when we all want to be a 10. Unless you have worked on over 10 different teams, I suspect you cannot see this as by travelling team to team you start to notice dynamics and certain teams not willing to try certain solutions. You start to see which teams are the 5′s and which teams are the 9′s.
Experimentation needs to be part of the culture.
I used to say Agile needs to be part of the culture, but I now believe you really just need to follow the two most important principles in Agile….Inspect and Adapt and Let the team Decide but do it in a hard-core fashion. These principles brought about the existence of all the other principles. If you don’t believe that, just read about the agile manifesto. Now, getting to this type of culture is not an easy one to get to. When it comes to a specific idea, there are people who don’t want to change and those who do. We need a process for changing culture. Something you can write down and apply. We also need something that makes change the one constant thing on a team. These may be small changes or large changes but the idea is to continually improve. If you are a process person this is to attain CMMI Level 5 which has continuous improvement. I don’t much care for process certification as better teams come from a better culture. Improve the culture and you improve the team.
Culture Change
How do we change the culture of our organizations then to become continually improving? This has never been easy and there have always been two main approaches to this
- top down
- bottom up
But my teams are comfortable/satisfied with the culture
As Torbin Rick put’s it, “people need to feel the problem” to want to change. This is that Dictatorial part of Dictatorial Democracy. If you have your team vote right now on “do they want to change?” the answer will be “we are a great team, why change”. You need to enact a sort of Dictatorial Democracy when bringing Agile in. What I love to do is bring a framework, the whole scrum process and then after 6 weeks of that tell the team they can now change anything and everything EXCEPT one thing. That one thing is the retrospective which I think works best in Dictatorial Democracy fashion. Everything else though can change. This is where the team now takes control and really shines. By this point, the team has adopted that culture and somethings will revert(because they need to and are better that way) and other things will be taken from Agile and expanded upon. The real key is to be rigorously and constantly asking the team how they can approve.
The One Key
The retrospective is the key to this constantly improving culture. Whether you choose to try to follow Dictatorial Democracy or another pattern, these meetings
- MUST be kept short
- MUST be a vote of if something is a problem or not on each item
- MUST be a vote on the solution to try for that problem
- MUST go through a readout and vote if problem X from last retrospective was solved
- MUST cut the meeting short instead of trying to solve every problem
But I have no time
Yes, we all hit this, but the fact is to follow the above, you really need 10 minutes a week for the retrospective and maybe 20 minutes of prep time before that retrospective. Then of course, there is solving the problem which the team will do and you will just track. There are many times when you ask if solution X was implemented and sometimes due to lack of time, it was not. This is fine and this is exactly why you do a readout asking the team if each problem was solved. This is key, you are NOT asking if solution X was implemented. You are asking the team if problem X was solved because if not, you may need the team to come up with solution Y 
.
“But I have not time”
It’s amazing how often this argument of “no time” gets used in the tech industry yet you never hear other professions say that. Did you ever hear a lawyer or an architect say that? If they did I wonder what the impact would be on the quality of their output? Dodgy bridge?!
Great point in that I should have elaborated here in the post(I may go back and edit later). Having been an entrepreneur and dealing with my lawyer who has his own business, I actually think we all have a “time” problem. I think the issue has always actually been where can I best spend my time. What is the best ROI for my time. Unless you have rigorously inspected and adapted to improve a process, you are not sure the ROI going in and are hesitant with investing the time there as you think other places may have better ROI. I have luckily been able to convince many managers that the ROI is better than most things…that is the key, THAT and the promise of very short meetings and no interruption to current work
.
[...] Culture vs Process – Predictive Project Management Predictive Project Management. Radical Views on Project Management. Image of Dean Hiller … I used to say Agile needs to be part of the culture, but I now believe you really just need to follow the two most important principles in Agile… … Source: blog.alvazan.com [...]