There are organizations which think that Agile or Scrum can be the solution to solve all IT problems that they have. Senior management has decided that their whole organization has to become agile. To realize that they demand that all existing (waterfall) processes will be replaced by Agile processes. Even if they succeed to do that (which is often not the case) they are usually not getting the expected business benefits out of Agile. Replacing processes doesn’t make an organization Agile.
Teams own their process
Agile teams are self-organized. They are capable to plan and track the work that they need to do. Team members are professionals who know how to do their work and how to improve their way of working with retrospectives. An Agile teams doesn’t like it when processes are imposed on them. It reflects a command and control style which is not effective.
In stead of imposing processes on teams, managers should work on the conditions for teams to define and improve their own processes. Some of the things that managers can do are:
- Remove detailed processes (or allow teams to remove them).
- Arrange training for team members to develop the skills that they need.
- Expect teams to work in a sustainable pace (and don’t put pressure them)
- Address impediments in the organizations that are raised by teams.
Managers should support teams in improving their way of working, for instance by:
- Allowing professionals to take time for improvements.
- Enable teams to self-assess how agile they are.
- Arrange agile coaching and mentoring for teams.
- Train and stimulating professionals in giving and receiving feedback.
- Ask teams to do retrospectives and support them doing improvement actions.
- Train retrospective facilitators to get more value out of agile retrospectives.
- Arrange opportunities for teams to learn from each other.
- Reward teams and professionals for improving their way of working.
Deploying Agile process frameworks
Taking an Agile view on your processes can still be valuable for your organization. Discussing agile values and principles helps professionals to explore and agree on how they want to work together and to become better and deliver valuable products to customers.
Agile frameworks like Scrum, XP, Crystal, and EVO are representations based upon the values and principles of the agile manifesto. I consider them to be similar to frameworks and models as TQM, CMMI, People CMM and Lean: They are valuable “tools” in the hands of professionals who understand them and deploy them based upon the context and needs of people. To simply do those things which make sense, not what the framework tells them to do. With focus upon the resulst that are needed, and not the model itself.
Don’t kill your teams with Agile silver bullets
Some organizations consider Agile to be a silver bullet to solve all problems with IT. They replace the processes by an agile framework ones and demand that everybody works like that. If it was that easy, then by now all organizations should have become Agile as agile frameworks have there for more than 10 years.
It can help a lot when managers develop a realistic view of what agile really is, and what they can expect to get out of it when they start their agile journey. Too often there’s the idea that agile can solve all problems, is something that is easy to do, that the team or the engineering department can do themselves (it’s self-organizing) and that it is just a matter of replacing existing processes by agile ones (For an example on this, take a look at can you use a Scrum master by Bob Marshall). Don’t make a wrong start by only hiring people and assuming that that will solve all problems. Be aware that as managers you also need to put in time to make agile successful.
Becoming Agile takes time. It starts with understanding the values and principles. And use that to deploy agile models and framework in such a way that it helps your teams to do their work and become better in what they do. Becoming agile is hard work, but when you start getting the rewards (which can be quickly) you know why it’s worth doing it.
(This post was published March 28 2014 and extended April 16 2014 with inspiration from a blog post by Bob Marshall).
Pity, but true. Just today I heard another story about management wanting to go Agile, and then denying their teams the mentoring, even after they asked for it together with the person who trained their Scrum-masters.
Thanks Angelo for sharing this.
If an organization wants to get benefits from Agile they have to take request from the teams and the professionals working in the team seriously. If you want them to be able to do their work in a good way, please listen to what they say and support them in the best way that you can.
In my previous company (a small startup) we started with no processes at all. Basically, we were just hacking code together with our best knowledge. Once the company started to grow we knew had to become more disciplined. After all, we were already serving large clients and building a fairly complex software and we had already experienced the pain that ad-hoc mentality caused to the quality of our software.
Our CEO was smart enough to suggest a radical change. He gave each team member a copy of a Scrum book (this one to be accurate http://www.amazon.com/Agile-Software-Development-Scrum-Series/dp/0130676349). I think this particular book was chosen because of the small number of pages in it, there may be better ones out there. We agreed to read the book and follow the guidelines provided. However, we also kept a freedom to choose to do differently wherever we felt so. We pretty much went on by the book. And it made a huge difference for the better.
It’s probably more difficult to make that kind of switch if the team has already long history of doing things in a certain way. We didn’t have much of history of working together so it may not be as applicable to your team. It did not solve all the issues for us either, of course, but it gave use a framework to discuss and benchmark our ideas.
I’ve now moved on to start another company along these ideas of helping software development teams to become more productive. Ben Linders, and others interested on the topic, we’d love to hear your thoughts.
Thanks for sharing your experience Sami.
Can you tell us more about how the CEO supported the changes in the organization after distributing the book? How did he suppport teams and professionals in becoming more agile?
Also it looks to me that the team didn’t have the feeling that processes were imposed on them by the CEO. Where there specific things that the CEO did that made people feel this way?
I think the key is to make the transition so that it feels like it was a common decision, not imposed by one person. You need to have each individual heard despite their position in the org chart. Start with open questions like “how should we produce software” rather than closed ones like “are you ok with Scrum”.
Let the team to decide. If you have a good team they will end up with something sensible. Isn’t in the core of agile principle that the team is trusted and self-organizing after all?
Handing over a book or a guideline written by a trusted third party saves a lot of time which will be appreciated as everyone is busy with their tasks anyway. Just make sure that the content is easy to digest (not too many pages). Have a meeting with everyone involved and write down the key points suggested. Make it clear that decisions are not “written in stone” but instead a start of an iterative process that can be improved over time based on experiences.
Chances are there’s not that many changes requested once the team gets in speed with the new process.
However, you need to be persistent. You need to have a PO who understands the duties involved. You need to have people involved in the meetings (plannings, reviews etc.). Have them scheduled in the calendars. Lot of people like routines, fewer people like uncertainty and surprises.
Thanks Sami for providing additional information on the way that Scrum had been introduced and how that affected the transition, very useful!
Hi Ben, I sooooooo agree.
I’ve seen this so many times, client side, as well as agency side, where management kneel at the altar of Agile while not really paying homage to it, if you see what I mean. A bit like idol worship, to stretch the religious methodology 🙂
My believe in fact is that there is a difference between agile culture and agile project delivery and while the former is doable in many organisations the latter is far more tricky (check this out if you like: http://www.thedigitalbusinessanalyst.co.uk/2014/03/does-digital-enterprise-have-to-be-agile.html)
m
Marcel, thanks for confirming my thoughts on how (not) to become agile!
I agree that there is a difference between agile culture and agile project delivery but they are alos related. There are many practices which are now called agile (most of them were there long before the term agile was coined). These practices are more effective when done within an agile culture and from an agile mindset.
E.g. if you want to do effective agile project delivery, then customer collaboration is extremely important. Same as transparency and openness to make sure that all involved know what the status is and are able to take the best decisions.
Marcel, Do you agree with this?
absolutely.
I think it all comes down to the level of acceptance of the agile principles. I quite like how DSDM Atern define them: http://www.dsdm.org/content/4-atern-principles
And even better, they even have a questionnaire to assess Agile readiness: http://www.dsdm.org/content/appendix-b-project-approach-questionnaire-paq
In practice the problem often is that we do all of these assessments, and then go on and ignore them 🙂
Thanks for sharing the DSDM agile principles!
Do you know my list of agile self assessment tools and checklists? It can really help organizations who want to become more Agile and Lean.
I’m working on a blog on “making actions stick which will address effective ways to improve based upon assessments, retrospectives, root cause analysis, etc. Until that one becomes available, there’s my bog on uncovering better ways to do process improvement for people who want to get things done.