The point of this blog is to demonstrate that making things simple helps becoming agile. Slight glitch: making things simple is a different kettle of fish than taking the easy option. Simple is not Easy!
Just about 2 years ago, we set up a 3-day workshop to capture user stories with our customers. Our supplier did attend this workshop. For each story we created, we added a few (1 to many) acceptance criteria using specification by example (Given/When/Then/And/But model). It did work great because even for the user stories that initially looked obvious, adding an example showed that there were still misunderstanding between participants about what the stories were about.
An example was (along the line):
As a driver, I want to get directions to a city in another country so I can travel to that city
GIVEN I am in France AND my system is in French
WHEN I say “go to Brussels, 123 main street”
THEN the system says “I did not recognise that – please try again”
The reason the system does not recognize an address abroad: this is a technical limitation that the supplier of the system raised. The customer had forgotten this limitation.
Bottom line, adding an example to a story avoids misunderstanding to a great extend.
That “specification by example” does is making the story simple to understand. Even a story well written may not be concrete enough hence having an example makes obvious what we want to achieve (and also generate discussions).
We also know what that agile architecture principles like to “keep it simple stupid”.
So if you make things simple (and this is hard), then you can become agile?
Look at what Mike Cohn and Ken Schwaber’s project noise level (from http://www.mountaingoatsoftware.com/scrum/a-reusable-scrum-presentation)
It took me a while to understand this slide (ok, did not pay attention to it first).
It just says (I am interpreting it that way), if you can make things simple, then you can be agile.
Scrum is made of short sprints forcing a team to break down requirements and technology simple enough to deliver a product increment.
As De Vinci said “Simplicity is the ultimate form of sophistication”
So Simplicity could be a path to agility, not an easy path!
Last but not leat, these are De Bono principles to simplicity:
- You need to put a high value on simplicity
To get simplicity you have to want to get it. To want to get simplicity you have to put a high value on simplicity. - You must be determined to seek simplicity
People quite like simplicity if it does not cost anything but are usually unwilling to invest resources in making something more simple. - You need to understand the matter very well
If you do not seek to understand a situation or process, your efforts will be ‘simplistic’ rather than simple. Simplicity before understanding is worthless. - You need to design alternatives
It is not a matter of designing the ‘one right way’. It is more a matter of designing alternatives and possibilities, and then selecting one of them. - You need to challenge and discard existing elements
Everything needs to justify its continued existence. If you wish to retain something for the sake of tradition let that be a conscious decision. - You need to be prepared to start over again
In the search for Simplicity, modify if you can – start afresh if you cannot. - You need to use concepts
Concepts are the human mind’s way of simplifying the world around. Warning: If you do not use concepts, then you are working with detail. - You may need to break things down into smaller units
The organisation of a smaller unit is obviously simpler than the organisation of a large unit. The smaller units are themselves organised to serve the larger purpose. - You need to be prepared to trade off other values for simplicity
A system that seeks to be totally comprehensive may be very complex. You may need to trade off that comprehensiveness for simplicity. - You need to know for whose sake the simplicity is being designed
A shift of complexity may mean that a system is made easier for the customer but much more complicated for the operator.
When talking about agile, lots of aspects need to be taken into account and implement at some points:
- Which agile framework? Scrum, XP, DSDM…
- What control and governance around the project? Prince2/DSDM, A-PMI, …
- How do we scale? Agile Release Train, Spotify startup product mindset,…
- How is portfolio management affected? Yearly budgeting and quaterly funding
- Agile Transformation: how we deal with HR? With Legal? With PMO? How do we make the organisation more agile?
Here below is a picture that represents the aspects to think of:
User stories have, in a way, bridged the gap between technical teams and the Business: we understand what you want and why; we speak the same language!
On the architecture side, this can be still be a black box for the Business or even for the scrum master and product owner: yes we get the idea but cannot really comment…
Looking at Domain Driven Design (Domain Model Principles), the tech team is going to model their “architecture” while interacting with the customers/users (PO).
Concretely, as the customers describe their business flows in front of the tech team, the tech team map out the flows to a model so the customers can understand how the system will handle these flows and spot any issues, missing constraints and requirements.
One great benefit from an agile point of view is that this is another “tool” to use to increase interactions between tech teams and the business to implement the right solution.
The use of ubiquitous language is key as “Ubiquitous Language is the term Eric Evans uses in Domain Driven Design
Short introduction:
http://www.typo3-media.com/blog/domain-driven-design-introduction.html
Video:
http://skillsmatter.com/podcast/design-architecture/talk-from-udi-dahan (quite good, some very good examples to see who it works)
http://www.infoq.com/presentations/model-to-work-evans (From Eric Evans – DDD: “putting the model to work” – a good example!)
http://www.youtube.com/watch?v=2fVTNsQ8POI (very theoretical at the beginning)
I have been looking at different agile project management frameworks and, although they may look similar, once again, this is the approach and the way they reinforce agile values that makes the difference. You would expect agile values to constantly flow through the project. So this is not what you do but HOW you do it!
I like the picture by KeithRichardConsultants as this is quite a good presentation of how to drive a project – Below you will find more information on other frameworks:
*/ WORK IN PROGRESS */
DSDM Atern v2: Pre-project, Feasibility, Foundations, Exploration, Engineering, Deployment, Post-project
Combining DSDM with Prince 2 (whitepaper) – KRC Consultants
DSDM Agile Project Management Framework for Scrum v1.1: Pre-project, Feasibility, Foundations, Sprints, Assemble/Review/Deploy, Post-project
Jim Hinghsmith: Envision, Speculate, Explore & Adapt, Close out
What needs to add is a Governance model:
An interesting article on gated processes: stage-gate-process
A agile project is still a project and information that covers a E2E project is still required. How this information is created and communicated will also depend on the framework used (e.g. Scrum) as well as the overall software development cycle and gates in place (I am following Jim Highsmith SDLC [Envision, Speculate, Explore & Adapt, Close out] and I have tried to summarize it here: the big picture )
Although in draft version, I am trying to see how a project plan can be easily created and how key information can be communicated. One could spend hours writing such templates as so much information can be added. The goal of this document is to cover areas the team will need to take care; not to do the work for them. An example is “As a team, have you considered non-functional requirements?”
In the spirit of agile and common sense, creating the project charter should be a team effort including stakeholders (based on Liftoff Launching Agile Teams Projects) and adding some (excel) tools such as Risks Management and Milestone Slip Chart.
I will keep building over the Xmas period.
Here is a second draft including some excel tools: Agile Project Plan Template v1.1
This document includes Excel Milestone Slip chart tool, Excel Risk and Issues management tool and Word Meeting Minutes tool (add actions, collect them in a table, set dates for you etc and I am quite happy to explain how they work.
(I have included reference to Lift-off and added a Scrum checklist).
Milestone slip charts (and other names such as milestone trackers) could help track key milestones in an agile project. The idea is that on a regular basis the project manager forecasts when the milestones will be met.
Because of scrum, you may not want to track features as they move according to business priorities. So what is left is milestones that won’t change because of business priorities. Let’s look at some examples:
1. Minimum Viable Product: scope of this milestone may change because of business priorities but the Minimum Viable product by itself will not change priority: you need one.
2. First run on production: whether this is one story or more, they need to run in the product environment meeting acceptable KPI(s).
3. Initial performance testing…
4. First release to external customers…
5. End of project (whether this is scope or date driven)
6. Start of Sprint 1
7. Stable velocity (normally within 3 sprints)
You can even follow Agile SDLC: Envision, Speculate, Explorer, Adapt and Close.
You can download the excel macro document that displays the chart for you: Agile Milestone Tracker Demo v5.47.
We are people!
Why does Scrum work? Why does such a simple framework work and sometimes fail?
In PeopleWare by By Tom DeMarco, Timothy R. Lister, the authors argue software companies are not really technology companies, they are people companies! And this is why Scrum works: Scrum is about people and Scrum fails when people fail to understand it is all about people and just think Scrum as a process to deliver software as opposed to a framework to engage and motivate people to deliver better software? Mike Cohn provides some “Twenty Tips to Help You Avoid Success” including “Start customizing an agile process before you’ve done it by the book!” (link). This is an important point here: Scrum is deceptively simple and it is very easy to be cavalierly around ceremonies, sometimes in the name of efficiency to implement stories rather than team’s effectiveness. Such ceremonies are made to engage and motivate people so that they deliver shippable products. Hence they are not directly aimed at delivering products: they really aim at engaging people! Once you customise Scrum, you take the risk to derail from the agile values and make Scrum a soulless process, without much common sense falling into mindless bureaucracy rather than quality as presented by Steve McConnel’s 10 myths of Rapid Development “Good processes are Based on Good Common Sense”:
Source: Telcordia Technologies: The Journey to High Maturity, Bill Pitterman, IEEE Software, July 2000
Scrum gives sense of purpose, Mastery and Autonomy
Dan Pink explains that 3 factors motivate people: Sense of Purpose, Mastery and Autonomy. So how Scrum (based on Agile values and principles) becomes an excellent framework to motivate people?
Sense of purpose
A short story:
An itinerant wanderer traveling over country roads in thirteenth-century France who comes across a man exhaustedly pushing a wheelbarrow full of rubble, he asks what the man is doing: “God only knows. I push these damn stones around from sunup to sundown, and in return, they pay me barely enough to keep a roof over my head”. Further down the road, the traveller meets another man, just as exhausted, pushing another filled barrow. In reply to the same question, the second man says: “I was out of work for a long time. My wife and children were starving. Now I have this. It’s killing, but I’m grateful for it all the same”. Just before nightfall, the traveller meets a third exploited stone hauler. When asked what he is doing, the fellow replies: “I’m building Chartres Cathedral.”
Some engineers have always been managed by (project) managers where “command and control” is just the way to get things done. Jean Tabaka (link) explains with humour how “command and control” lowers IQ of your team and hence lower IQ of management (and as a former colleague of mine replied “Is that possible?”): engineers are not just builders, they want to create and build hence, as a Product Owner, you need to give them a sense of purpose: something greater than just fulfilling their basic needs!
Scrum helps: get the team to contribute to creating user stories and use “lift-off” sessions to engage them (see “Liftoff: Launching Agile Teams Projects” book by Diana Larsen and Ainsley Nies). Explain the team you want to build the “cathedral of Chartres!”.
In a nutshell, Scrum helps teams create and build something great giving the team a real sense of purpose!
Mastery
With Scrum, this “Hero” culture is vanishing in favour of the team capability to deliver. Through sprints, “storming, forming and norming phases” should be quick, especially around the Scrum master. Through planning poker, daily stand-ups, sprint review, retrospectives and planning, there are lots of opportunities for the team to get to understand each other.
Regarding Performing, we are not talking about efficiency, it is about effectiveness. To explain the difference, climbing a ladder very quickly to realise you have the wrong wall can show you are efficient but ineffective.
So with Scrum, you are likely to realise you have reached the wrong wall at the end of the sprint, when you demo your product. And worst case scenario, if you have a Minimum Viable Product, an MVP (see The Lean Startup) your earlier customers can try out, you will get critical feedback!
The team is going to learn to work together, to reflect on their practices through retrospectives, they are going to pick tasks of their own choosing (based on business priorities) giving them opportunities to learn skills, areas of code they don’t know etc.
There is no mastery without learning: as a Scrum master, you want to make sure the team is constantly looking for opportunities to learn and that failing is just part of the game. You may want to make sure team members don’t just pick up tasks that keep them in their comfort zone but on the contrary, they pick challenging tasks, work together (maybe using pair programming) to get their commitment done by the end of the sprint. You use demos (sprint review) so they can proudly show what they have created and built!
Not only the team is going to help create the product and build it: they are defining what “built” means and they improve what “built” means. They define their standard of excellence: their definition of Done! RallyDev is providing some very good guidelines how to engage the team to create it, get them to commit to it (they are defining it) and put it on the wall. “Cult of Quality”, building great products, motivates teams as explained in PeopleWare!
Mastery with Scrum is mastery of the product building process and also mastery as a team to work effectively together against standards set by themselves!
Autonomy
A fundamental mistake I have seen is around what self-organizing means: this is “self-organizing around the Scrum framework”, not “just self-organizing”. Hence the importance of the Scrum master in getting teams self-organizing should not be minimized. Believing you don’t need a Scrum master, or need a Scrum master temporarily could be a fatal mistake: teams are humans and they need a shepherd, somebody not only there to remove impediment but also to inject energy into the team (a great video from Mike Cohn on Self-Organizing teams: link)!
Scrum empowers and gives responsibility to the team to deliver the product. Of course, “with great power comes great responsibility!” (Spiderman or Voltaire) e.g. responsibility to deliver their commitment is critical, getting a sense of their velocity, Attending 15 minutes daily stand up on time, reporting release burn down chart, number of defects etc
Of course a challenge is for management to trust the team and the team has to give confidence to management.
At the sprint planning, team is responsible to work out how they will deliver the sprint backlog. During the sprint, based on their commitment, the team has to work together to deliver the sprint backlog
Conclusion
There are far more tools using Scrum that helps teams engage, get a sense of purpose and remain motivated to deliver a product that delights customers: sprint goal, story mapping and learning new skills such as Test Driven Development and Acceptance Test Driven Development.
Agile set of values based on empirical facts and experience, full of common sense as well as agile principles believes in people over anything else… I recently read that “What matters is the quality of people. The rest is just an optimisation!”. Scrum is not the solution. Scrum helps make teams more effective: keep people engage, motivating and learning while, as a team, deliver products. It helps keep good people, make them great and make teams hyper-productive!
Last words: think of your people e.g. engineers and Scrum masters as “creators, not builders”!
