‘How Not to Be Agile’ may seem a strange title for blogs about how good Agile is. The benefits that can be obtained from adopting an Agile approach are well documented all over the web. What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits of Agile when an organisation, or part of it, embark on an Agile Transformation.
The content of all my articles is based on my personal experience from my training and coaching practice; there will be no ‘third party’, apocryphal stories that I do not know the truth of.
Agile Transformation is not easy! Yes, the ‘mechanics’ of all the Agile frameworks are relatively straightforward to implement, given that people are trained adequately.
However, the root cause of just about all the problems that I have come across is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.
Let’s start with the importance of the Vision and Objectives of whatever it is that we are trying to achieve.
Vision and Objectives
Right before the headlong plunge into the vision and objectives of an Agile team, you should first know whether your team and Agile are meant to be together.
Simply put, do not adopt Agile just for the sake of being Agile. The following diagram will help you understand the situations wherein you need to have second thoughts before embracing Agile.
Most of the popular Agile frameworks such as Scrum, eXtreme Programming (XP) and Lean Software development, start the process from ‘given a set of requirements, ordered by business value, this is what you should do’.
The problem with such frameworks is that they give no advice about deciding whether the development initiative should even be started in the first place; they assume that an organisation that is adopting their framework, already has processes in place to create things like Business Cases and do ‘Portfolio Management’. But even if these, what I call, ‘governance processes’ are in place, they are usually based on the organisation’s current ‘waterfall’ approach to product development and are generally unsuitable for Agile development.
Notable Agile frameworks that do include some, if not all, governance considerations are the Agile Project Framework, from the Agile Business Consortium; the Lean Startup and the Scaled Agile Framework (SAFe®).
Vision Statement
Ideally, a Vision Statement should be of one or two sentences mentioning the problem to be solved, who has the problem and the benefits of carrying out some development; it should be aspirational, i.e a target if the best-case scenario is realised. Eg:
“To solve the problem of the Board not having ‘real-time’ financial information available in order to make better strategic and tactical business decisions”
In this example, it is clear who has the problem- the Board. And also, what the problem is- no real-time financial information; the benefits are implied in this example, it is probably obvious that it is important for the Board to be able to make good strategic and tactical business decisions.
" style="height: 402px;">
Objectives Clearly, it is not possible to scope a development at any level directly from a Vision statement such as the example above:
What specific financial information do the Board members need?
Which Board members need it?
When do they need it?
Which decisions are affected?
When does this ‘improvement’ need to be in place?
Questions such as these can be answered in a list of Objectives:
1. Current, ‘real-time’ information about {x, y, and z} needs to be available 2. The information needs to be available to Board Members {a, b, and c} by the 25th of each month. 3. An improved financial reporting system must be in place by the beginning of the next financial year with a minimum of information a (the Minimum Viable Product) and hopefully with information b; the best-case scenario is that c will be included as well.
We can see that this list of objectives gives us clearer detail about who to focus our efforts with and what to focus our efforts on.
Objectives are not Agile requirements.
We don’t measure Vision statements; we can measure Objectives. So what problems have I encountered with Vision?
Case Study 1:
I had been asked by a member of an organisation to conduct an ‘Agile Audit’ of a large development programme that was supposed to be a part of the organisation’s Agile Transformation. He had asked for the audit because he was finding it difficult to see the benefits that the ‘partner’ development company had promised.
For those of you yet to acquaint yourselves with Agile Audit procedures, a standard audit template may look like the one shown below. Following a similar variant, not just for Sprint planning, but also for other ceremonies in Agile can help find and fix impediments.
Initially, I concentrated my audit efforts with the numerous development teams (12), finding many ‘horror stories’ that, if you stick with me in this series of articles, you will read about later.Having submitted my audit report, I was asked to stay on to help sort out the mess; I became part of the programme management team.
It became clear to me, when interacting with the different teams, that there was no consistent view of why they were doing what they were doing or what the expected value of what they were doing was supposed to be; they were used to being told what to do and they did it like they had always done; some good, some bad. The teams were made up of some of the organisation’s internal people and people from the ‘partner’ development company.
Core checklists
Recommended checklists
Clearly defined PO
Team has a sprint backlog
Daily scrum happens
Demo happens after every sprint
Definition of done available
Retrospective happens after every sprint
PO has a product backlog(PBL)
Have sprint planning meetings
Time Boxed iterations
Team members sit together
Team has all skills to bring backlog item to done.
Team members not locked into specific roles.
Iterations doomed to fail are terminated early.
PO has product vision that is in synch with PBL.
PBL and product vision is highly visible.
Everyone on the team is participating in estimating.
Estimate relative size(points) rather than time.
PO is available when team is estimating.
Whole team knows the top 3 impediments.
Team has a scrum master.
PBL items are broken into task within a sprint.
Velocity is measured.
Team has a sprint burndown chart
Daily scrum is everyday, same time&place.
I asked the programme manager and some senior programme business people what the Vision and Objectives for the programme and the Vision and Objectives for the transformation were and was assured that they existed but nobody could tell me where; there were some attempts to tell me what the Visions were but, again, there was no consistency.
One afternoon, the equivalent of the CEO had a space in her diary and decided to visit the development area. After some organisational ‘notices’ she asked if there were any questions; silence!
This typically happens when right at the inception of the project, a clear product vision is not drafted in a discrete format as the one shown below-
So I asked her if she knew where I could find the Vision statements and/or Objectives for the programme and/or the Agile Transformation. She assured me that they existed and dispatched one of her aides to my PC to find them on the intranet. Fifteen minutes later, the aide found a section of a document, on page 34 of that document, titled ‘Vision’; the section contained 3 paragraphs none of which described the problem that the programme was trying to solve nor the benefits that were being sought. He could not find an Agile Transformation Vision or Objectives of any description.
I told the programme manager of my unease about a visible and adequate programme Vision and the fact that I was uncertain of the business value of some of the programme projects but had no ’yardstick’ to measure the value by. One project had been running for about 18 months, had spent £1.5 million, and had delivered nothing!
There was an attempt to measure the value of the projects by the 3-paragraph Vision and it was decided that the project mentioned above was not even in the scope of the programme; the project was cancelled. Three other projects had their scope reduced but they had already developed parts of the original scope that were removed.
Lessons: 1) Without a visible and concise Vision statement and list of Objectives at programme and project levels, it is highly probable that the scope at both levels will end up being something like ‘that seems like a good idea – let’s do it’. 2) Without a Visible and concise Vision statement and list of Objectives at programme and project levels it is highly likely that money will be wasted; anathema to Agile. 3) Governance is not just about what is happening, ie progress, it is also about why it is happening; in the beginning, and the ‘why’ may be reasonable but times change and governance processes must investigate whether the ‘why’ is sustainable; initially, in no development reviews that I attended, nobody asked the question ‘is the business case still viable?
Case Study 2:
I had been asked to do some Agile coaching for some teams in a global organisation that was undertaking the Agile transformation of one of their divisions; the transformation had been running for 6 months.
Imagine my surprise, when starting the assignment, to find that none of the teams were involved in product development but were supporting existing systems; this support did not involve ‘coding’ of any sort, just manipulating the data; the team members had a role of ‘Analyst’.
I was further surprised to find that some of the teams were organised into SAFe® Agile Release Trains (ARTs) and using Scrum.
The clear majority of product development in the organisation was done by another division and Agile was not being used. However, when the product development teams needed analyst support, they co-opted members of the support teams thereby reducing the capacity of the support teams.
As in Case Study 1 above, there were many anti-Agile practices in place which I shall cover in later articles.
Firstly, I asked the division’s senior management why they were undertaking the Agile transformation. The answer was that the previous practice of some analysts being permanently with the development teams and the others permanently doing support, was not liked by the analysts and they were ‘mixing and matching’ within analyst teams. A worthy ambition, but I was not sure how they expected Agile to solve the problem.
So I asked why the ART teams were using Scrum when Kanban was probably a better fit for the work that the teams were doing; SAFe® allows for the ART teams to use Scrum or Kanban. I was told that it had been decided that all ART teams were to use Scrum for consistency; the answer to my next question informed that decision.
Then I asked why they had chosen SAFe® given that SAFe® is designed mainly for product development; SAFe® does allow for product support teams in the ART; such teams usually use Kanban. I was told that the product development division had experimented with SAFe® for a product development and it was considered very successful. Based on that success, the division that I was working with had decided to implement SAFe® ‘en-masse’.
None of this information was written in a transformation Vision Statement nor were there any transformation Objectives with which to measure how the transformation would be measured.I am not dogmatic about Agile practices, even the ‘strange’ ones being employed by this division. I decided to help the teams where I could.
With many team members, I encountered a reluctance to follow some of the basics of Scrum which was slowing their work.
My anecdotal issues about the team members’ reluctance and lethargy that I raised with the division senior management were all met with ‘show us proof’.
After 3 months, it was decided to run a ‘team health check’ exercise with all the teams globally. It was further decided that this health check would use the Spotify Squad Health Check Model by which team members are asked various questions about their team and respond via ‘traffic lights’; red, amber or green.
The diagram below outlines the popular health check metrics followed by highly functional Agile teams. One of the questions asked was about ‘Suitable Process’ with ‘Our way of working fits us perfectly’ as green and ‘Our way of working sucks!’ being red.
I ran the health check with the teams that I was directly responsible for and some that I wasn’t. The answer they gave to the Suitable Process question was overwhelmingly red with a few ambers; there were no greens. I sat in on a couple of the health checks run by the senior coach; he did not use the ‘Suitable Process’ question and avoided any discussion about the process; I realised that there were politics in play that I hadn’t previously been aware of.
Lessons:
1) The division clearly understood the problem that they were trying to solve and who had the problem but the solution was inappropriate. Without a transformation Vision Statement and suitable Objectives List, it is likely that an inappropriate solution to the problem may be selected.
2) Without a suitable list of Agile Transformation Objectives, it is impossible to measure how the transformation is progressing and to find impediments to the process that need to be addressed.
Discover your full project management potential with our online PRINCE2 Foundation certification. Master the industry standard methodology and take your career to new heights!
Conclusion One of the tenets of Agile is to ‘Fail Fast’. If you set out on an Agile Transformation, a product development programme or a project without everybody involved knowing:
What is the problem that we are trying to solve?
Who has the problem?
What benefits the initiative is expected to bring?
you will probably:
Waste money
Choose the wrong solution
Alienate staff
If you do not have a list of measurable objectives for the initiative:
You cannot check the initiative progress
You will not identify initiative issues that must be resolved
You cannot ‘fail fast’ and pivot your solution
Basic speculations and uncertainty aside, if you strongly intend to run a healthy Agile team, this is how your Agile journey should look like.
Steve Ash
Blog Author
Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’. He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner. He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
Share This Article
Ready to Master the Skills that Drive Your Career?
