Agile/Scrum is a relatively simple framework in concept. If you watched the Scrum Training Series videos I recommended in my first post on Agile/Scrum, you understand that well.
In execution, the concept is often sabotaged by a lack of attention to the key concepts that make Agile/Scrum successful. Don't be that person.
This post will cover the main points of the key concepts. In later posts we will cover each concept in more detail.
The Agile Manifesto
A group of smart people came up with the Agile Manifesto in 2001, which is the philosophical grounding of an Agile/Scrum framework.:
It's important to note that these are priorities, not statements of exclusion.We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more. [emphasis mine]
The People
- The Product Owner - The voice of the customer and source of the product vision
- The Scrum Master - The arbiter of process; insures the key meetings are executed properly
- The Development Team - the people developing the product; developers, testers, UX (user experience) and UI (user interface) experts, etc.
The Product Backlog
- The greater its value to the customer
- The higher its priority
- The more defined it is
The Product Owner has the ultimate ownership of the Product Backlog, being the ultimate arbiter of the ranking of stories on the stack. User Stories in the Product Backlog can be changed by the Product Owner at any time.
The Meetings
While Agile/Scrum is relatively unstructured, there are some key meetings to make the process work:
- Backlog Grooming and Refinement* - refine, reprioritize, and estimate development time for stories
- Sprint Planning - decide which stories will be developed in the current sprint
- Sprint Review - demonstrate new product increments to stakeholders
- Sprint Retrospective - team after action discussion
* - Some consider this unofficial/optional, I do not. It works beautifully.
The Sprint
Sprints are rigidly time-boxed. They range from one week to one month in length.
Sprints are where development happens. There are no "requirements sprints"
Sprints are fluid, iterative activities. The various design, build, and test activities of development are performed dynamically throughout the sprint, not according to a project plan.
Sprints turn stories into potentially-shippable product, or nothing. There is no partial credit in Agile/Scrum.
Protect The Sprint
Do your best to insure your team is not distracted by outsiders, outside activities, or their own team mates. The team should be focused on the sprint goals. If there is a defined Scrum Master, that person should be in charge of keeping people from distracting the team.
If people want to come talk about the future features, suggested changes to the product, etc., they should be routed to the Product Owner. The team has one priority - create product for the stories they originally agreed to address for the current sprint.
The Concept of "Just Enough"
It is a natural instinct to want to completely flesh out your product/concept/software before you start work. But we have lots of instincts that are not necessarily great for efficient execution of tasks. This instinct has to be overcome for Agile/Scrum to be effective.
A typical Waterfall process will involve documenting 100% of your requirements down to the last detail, then designing 100% of the solution down to the last detail, then developing 100% of the solution, and so on.
Why could this be a bad thing? This approach dramatically reduces your capacity to be responsive to the customer and the market. Twelve months into your product development, if your customer comes to you in a Waterfall process and conveys that their priorities have dramatically shifted, the typical choices are 1) going back to the drawing board or 2) pushing out what you have anyway and then trying to accommodate your customer in the far future as you create a new version.
Agile/Scrum, on the other hand focuses on knowing just enough to progress. You just need enough stories on your product backlog to keep your developers busy in the next sprint.
It Starts With A Vision
Some people like to speak of "Iteration 0", "Iteration 1", and so on. I appreciate the logic behind it, but it's not how I prefer to approach it. I prefer to simply get busy as quickly as practical.
Have a clear vision. Understand the customer's or market's priorities. Start knocking out some stories and get busy making product. Just enough to keep the team busy for the sprint is all you need.
It's unsettling at first, because it feels very much like a leap of faith, and you're brain may be screaming, "but what if...?!" It may say that many times, in fact.
But it really does work, if you let it. While that first sprint is kicking off with a few high value features, you can sort out more stories, refine your vision, and it won't be long before you are anxiously waiting for the development team to get caught up.
Yes, there will be reformatting and changes in course. That's okay. The process is built to handle that. The good news is that Agile/Scrum is *built* to handle that.
As we discuss some of these concepts in more detail, I will do my best to point out how they feed into a successful process both directly and indirectly.
Let It Work
One of the key difficulties I see is people trying to burden an agile process with Waterfall-like concepts, artifacts, and processes for a sense of comfort. It's a dangerous game to play. It does not take much to sabotage the benefits of Agile and basically create a confused Agile-Waterfall hybrid.
So, if you do embark on the path of Agile/Scrum, I encourage you to go "all in", so to speak, and give it a shot. You may be amazed at the results.
No comments:
Post a Comment