My Stories Are Bigger Than Your Story
Big Stories...
I've always found it a challenge when new teams are adopting scrum but have simply renamed their list of requirements as a product backlog. Scrum provides a nice facade which shows a steady progress of churning through these requirements, but it makes it extremely difficult to measure the tangible business value. This is particularly the case where we have a scrumbut model, especially when done doesn't include production/release.
The progression from a list of requirements to user stories with acceptance criteria is usually the first step I recommend, but this is fraught with danger. Requirements typically have inherent dependencies that don't translate well into stories and requirements are also usually solutions to problems rather than the problems themselves. It is only by uncovering the underlying problems that we can start forgetting about the "requirements" and start providing tangible business value by solving business problems.
The first stab at cutting user stories usually results in very large stories with very vague, subjective acceptance criteria, if indeed there are any acceptance criteria. As teams work on these large stories, the tasks they produce are also probably too big and vague and simply sit forever in the in progress column. This is usually due to blindly trusting and following the scrum process. At this stage I usually challenge teams to stop tracking tasks and instead focus on delivering the stories. This is extremely uncomfortable at first since teams will be struggling to deliver big stories. However, it only takes a sprint or two before the team start focussing on the stories and feel relieved that they don't get bogged down in 3 or 4 hour planning meetings to produce extremely detailed task breakdowns. The tasks are still extremely important to capture and update, but this is more of a real-time activity and no-one gets penalised for adding new tasks, or removing tasks that are not needed any more...
This hybrid scrum/lean model provides much greater opportunity to start introducing new technical practises (e.g. test first, automated acceptance testing, etc) since stories are broken down at the last responsible moment and some stories are natural candidates (comfortable technologies, clearly defined, etc) for trying new things.
The next challenge I usually face is getting stories to a size that is acceptable for the team and the PO. Applying the INVEST model works quite well here as does parking open questions through agreeing to raise future stories as required to limit the scope of the story in question to something that is estimatable. At this point stories can become quite small (which is great IMHO) with perhaps only 1 or 2 acceptance criteria. This for me is the sweet spot. It means the story will probably fit in the 2 hr to 2 day window, it is well understood, it is easy to estimate, it is easy to test and a host of other great things... However, it will also probably invalidate any existing (but also highly dubious) velocity metrics since the team will need to rebaseline...
Scrum
I've witnessed scrum applied extremely well, when supported with some additional technical practises and good story discovery/acceptance criteria/backlog management, but more often than not in my experience scrum is applied as the smoke and mirrors over the requirements list to demonstrate progress and it's only when you hit the last sprint you realise that you can't integrate/release/deliver despite having completed 90% of the requirements before entering the sprint with only a couple of requirements to go (e.g. Oracle Auditing and Secure Messaging)...
Limitations of “Grow Your Own” Agile
"Grow Your Own"
Over the course of my career I have worked at several organisations and have always tried to improve the internal processes using agile techniques and principles. Despite being a valued employee (I hope) at each of the companies I have worked at, the amount of success I achieved in agile adoption always reached some internal limits. It was only when I joined emergn that I was able to rationalise this.
It is inevitable that as an employee of a company you will have something to do as part of your day job. This will always be your primary concern and there will inevitably be certain processes you must follow in order to perform your function. Changing this process from the inside will usually involve challenging the process (rocking the boat) using rational arguments and demonstrable alternatives. This is certainly achievable, but does take rather a long time to introduce even simple improvements. Organistations, particularly large organisations are not content with local optimisation and nearly always want to ensure that any benefits from a single improvement become the standard for the organisation as a whole. This usually means that the number of interested parties is artificially (and politically) quite significant and therefore the amount of resistance to change is high.
As an external coach the mandate is entirely different.
First and foremost, your primary function is to instigate change.
This will mean the amount of resistance is significantly less.
Secondly, you will not be tied to existing processes.
This means you can implement changes and improvements much faster.
Thirdly, as an outsider you are automatically assumed to be an expert.
This will mean that you will not need to engage in the same level of rational argument or discussion as an internal employee.
Lastly, as an outsider you bring some diversity and objectivity to the environment.
You will not be unconciously constrained by any existing processes or internal preconceptions about the art of the possible.
As an external coach now, I am actually extremely surprised with just how much compromise I had been willing to unconciously accept as an employee. Every small improvement I would have liked to make became a battle and unfortunately I lost many of these battles not through a lack of rational argument but through a lack of energy or time to continue to fight. When push came to shove I had to get on with my day job and ensure I lived to fight another day. Reflecting now, I'm not surprised that the more successful some of the improvements were the bigger the political entourage became and the more difficult it became to make the next improvement. Battles had to be chosen carefully not necessarily for the potential benefit but often based on the people who had expressed an interest.
I'm aware (and quite proud) of the changes I've made in each of the organisations that I've worked at but am left reflecting whether the effort was worth it. I think the barriers to continual improvement are probably a major factor when I decided whether I wished to remain at a given company and I can now see that effecting change from the inside is simply not effective. It will take at least twice as long to be at most half as effective as an external coach.
Qualities of a Good Developer?
Just what exactly is it that distinguishes a good developer from an average developer? Certification in a particular language or technology demonstrates the ability to be "average", but certainly doesn't demonstrate good. I believe a good developer is someone who has an aptitude for developing, which is inherently extremely difficult to measure or quantify. However, there are possibly a few things that can help you identify your good developers:
- They are capable of using several languages to get things done
- They are pragmatic in their approach
- They understand the concepts as well as the solutions
- They can think at multiple levels of abstraction
- They can get things moving despite uncertainty
- They champion quality and continuous improvement
- They like to share their knowledge and expertise
Of course, these are very subjective measures and very hard to qualify or quantify. It can be very hard to demonstrate an ability to use several languages if the working environment dictates a single language. Red tape may prevent pragmatism. If the environment prevents these qualities being expressed then it is very likely the most important qualities of the best developers are being suppressed.
If you wish to get the best from your best developers, and achieve that 10 times productivity that is often quoted, you should look to make sure that you have provided them with an environment that allows them to demonstrate (through action) the above characteristics. If there is anyone you can think of right now with some or most of these characteristics, why not take the opportunity to ask them how you can help to allow them to improve.
God Mentality
My recipe for developing a God Mentality.
Ingredients:
- a team of non-agile developers
- a single zealous (or inexperienced) agile coach
Method:
- Prepare a clean team working area
- Gently introduce the agile coach to the team
- Gently stir until a process emerges
- Trust the coach
- Allow process to fester
- Praise the coach
- Serve with a slight pinch of sarcasm
Adopting agile is extremely difficult and coaching is a great way to being in the necessary skills and expertise to a team. However, coaches are not infallible and will inevitably leave their own stamp on your project. Leave a single coach on a team for long enough and they will become an almost god like figure and the team will depend more and more on their advice and wisdom (KB/C3). A good coach will be able to adapt the processes and methodologies to suit your environment, but a zealot will probably insist on adapting your environment to match the methodology. To produce a really good God Mentality it is imperative that they are unquestioned in their approach and instead followed blindly. This works particularly well with a team of inexperienced (or long serving corporate) developers.
Unfortunately, if you fail to produce the perfect God Mentality, you're probably doomed to a life of perfect agile. The moment some diversity is allowed to challenge the preaching from God #1 you are on your way to never exalting a single guru (or their processes) again...
Unfortunately, the quality of agile coaches varies remarkably and this recipe may not always produce the perfect God Mentality.