I know there are more than a few Agilists who are bloggers among us and even more than enjoy taking pictures of their families, friends, their work, and maybe even their food on occasion (admit it, you do it).
[The following is from: https://www.gov.uk/service-manual/agile/what-agile-looks-like.html – What is so amazing is that this is a government website… yes. A GOVERNMENT website. I copied it here because I was so stunned… this is great stuff. Almost like Barack Obama telling us to do Agile]
Agile is a liberating way of working. It does not preclude the use of existing skills and knowledge. But it does require teams, users and stakeholders to adopt new ways of working together.
This short guide lists a few of the behaviours common to agile projects that support successful delivery and learning.
Understand your users
Prioritise features for them over everyone else – including your big, scary stakeholders, and seek their feedback early and often. Really listen to them. Even when they tell you things you don’t want to hear or disagree with. If possible, use data from real people using your product to influence the direction of the project. Your focus on the user should be relentless.
“What do you want next Friday? What have we learned last week?”
Iterate often. Build something focused on the next most valuable user need and show it to them; listen to their feedback and improve it. Keep doing this until you have something so useful that they would not be without it.
It perhaps sounds like over-simplifying the complexity of software development and project management, but at its heart this is what agile development is all about: “What do you want next Friday?”
The process of delivering incremental, production-ready software allows a team to deliver value to their users and stakeholders regularly. It shortens the feedback loops that might otherwise have been longer using a waterfall methodology. An iterative delivery cycle also forces the team to think about what the most important features are to deliver next and focuses the mind on useable software.
At the end of each delivery cycle, or sprint, teams should run aretrospective to review ‘what worked, what could be improved’ in the next sprint.
The software and the team continue to learn through delivery and iterate and improve throughout the project.
Small, agile teams
Small teams of between five to ten people are often more productive and predictable than larger teams. Forget man-days and think about the team as the unit of delivery.
A good team includes members with all of the skills necessary to successfully deliver software. A fully-functioning team has three key roles embedded into them, usually full-time:
Product Manager – responsible for delivering return on investment, usually by creating products that users love. The team delivers the Product Manager’s vision.
Delivery Manager (a.k.a. Scrum master or Project Manager) – is the agile expert that is responsible for removing blockers (things slowing a team down). They also usually act as a facilitator at team get togethers.
Team member – Self organising, multi-disciplinary team that delivers prioritised user stories. Responsible for estimation.
You help each other and work together toward delivering your sprint goals. It’s common to encourage team members to pair. It sounds counter-intuitive to have two people work on one thing, but this is not so. Working together closely produces better software solutions, promotes better quality controls and spreads knowledge across the team.
A good team can estimate their output, or velocity, very effectively and consistently. This allows for much more accurate planning.
Releasing little pieces of code often improves quality and visibility and reduces cost to market, but using agile techniques does not guarantee success. You can still fail! What agile methodologies do allow you to do is to spot problems earlier and resolve them.
Here’s a few examples of how:
- releasing working software to your users often allows you to get feedback quickly and hear or see what they think. If the product is wrong you can easily change direction and iterate.
- if your software is rarely released to production you are not demonstrating value to your sponsor. You run the risk of creating a “too-big-to-fail” service that isn’t fit for public consumption but must be released anyway. That means another press headline! Ship! Ship! Ship!
- if your teams’ velocity is consistently volatile, beyond the initial 4-6 sprints, then this is indicative of something that needs fixing. Perhaps there is hidden complexity or poor estimation.
- Test Driven Development (writing tests in code before you develop the features) has a wealth of metrics that highlight quality issues early. Establish what these are early on, baseline and monitor throughout the project.
Don’t be afraid to fail or experiment. Learn to fail, and create a culture that learns from failure.
It’s a myth that you don’t plan on agile projects. The freedom of agile projects does not come free: you have to plan. You just plan differently and continuously.
Agile planning is based as much as possible on solid, historical data, not speculation. The plan must continuously demonstrate its accuracy: nobody on an agile project will take it for granted that the plan is workable.
Typically teams plan together, usually on at least two levels:
- at the release level, they identify and prioritise the features we must have, and would like to have by the deadline.
- at the iteration level, they plan for the next features to implement, in priority order. If features are too large to be estimated or delivered within a single iteration, they break them down further.
These plans are usually reviewed after every sprint and adjusted based on “the weather yesterday”, new facts and requirements that will inevitably be uncovered along the way.
Teams new to agile should be wary of these familiar situations and reactions to doing things differently. They have a bad smell about them and undermine your project and its chances of success.
- Your team is not full time. If your core team of product manager, scrum master, and key members of your multi-disciplinary team are not on the project full-time and spread over many projects then expect difficulties. The team is the unit of delivery and you need focus. Push back on managers and stakeholders if this is happening.
- You don’t have a dedicated team area. Your team should be sat together, preferably in your own room, with space on the walls to draw ideas and stick up cards and post-its. As the project gets going, consciously ‘hack the environment’ to create a working environment conducive to team working. You might upset a few people and challenge some long-standing working practices. But this is so, so important, and really should not be a big ask.
- There’s no continuous integration environment. Start right: with a continuous development environment. If your teams are not insisting on this from the outset then you’ve probably got the wrong team. So much about iterative software development is contingent on the ability to continuously deploy and run automated tests as you do.
- You have a separate QA department. If your team’s attitude to quality is to throw the software they’ve developed over the wall to a QA department, then they’ve not got the right attitude to delivering production-ready software. You need to embed a quality culture into the team.
This is by no means an exhaustive list, but these are most common things to watch out for.
I had the honor of doing a keynote talk for the first annual Agile Dev Practices Berlin 2013 on Behavioral Science, NeuroScience, and Psychology [click for keynote slides].
The picture above is what community looks like. The picture above is what spreading love and appreciation for people looks like.
This is why I love our Agile community. This is why I’ll never leave it. #purejoy
[At Agile Dev Practices Berlin 2013]
Principles of Kanban
- Start with what you have
- Agree to pursue incremental evolutionary change
- Respect current situation
- Encourage leadership on all levels
Practices of Kanban
- Limit WIP
- Manage Flow – Monitor/Flow of reality
- Make policies explicit
- Introduce feedback loops
- Improve collaboratively
After a long 12 hour [total through Amsterdam] flight I’m finally here! I’ve been looking forward to speaking at Agile Dev Practices Berlin 2013 for almost a year now… super excited about my talk on Behavioral Science for High Performing Teams 🙂
The tutorials look amazing!
I like the cartoon. Reminds me of AgileScout 🙂
It’s good to be back in Atlanta. Actually I never left (in spirit). But it’s been almost 2 years since I’ve been able to really get back into the community here. I’ve been so busy traveling (client work)!
This past week I spoke at the Scrum Atlanta Group and boy was it fun. Meeting new people, seeing some old faces that I haven’t seen in a good while and just catching up on the vibes here. Atlanta has a great Agile community, people who are really interested in making big changes and bigger differences in their lives and companies.
I also met more “Agile Coaches” located in the metro Atlanta area than I would have ever guessed! I guess Atlanta is finally attracting good talent to help companies thrive. I’ll be honest, 2 years ago, I could probably only count the number of Agile consultants on one hand in Atlanta. Now there are many more. This is a GOOD thing!
Keep Atlanta alive. Keep hope alive. Build your Scrum business in Atlanta. You’ll have great support from a community that cares about building great companies in Georgia.