We’ve been blogging on many Agile topics over the last few months - initial Agile adoption, culture shifts, organizational change, product ownership and project management, among others. These topics, for us, often conjure up images of the people who read our blog. Some readers might be in a more traditional camp of software development and a bit skeptical of Agile. Others may be “biting at the bit,” as it were, to adopt Agile or to keep their Agile practices ever-maturing.
Enter our new Agile Blog buddies, Walter Fall and Sarah Scrum. We bet you know someone like these two readers.
Who is Walter Fall?
Walter is well-meaning but may be just a bit stuck in an old school way of doing things (The guy still carries a comb just for his mustache for goodness sake!). He holds fast to the practices he has accumulated over the years and is happy with where his career has taken him. Walter has been with his company for 20 proud years and now runs a division of ~120 people, all organized in functional teams. Walter’s VP, a golf buddy, recently brought in a full-time consultant named Sarah Scrum to coach him and his group on adopting Agile practices. Walter is unamused, but he’s willing to listen, if only to prove her wrong.
Who is Sarah Scrum?
Sarah is passionate about Agile. She seeks continuous improvement, almost annoyingly so. She loves a challenge and has found Agile to be a valuable resource for tackling technical and organizational challenges. Sarah has worked with Agile teams for the last 7 years leading them through maturing and scaling their Agile adoptions. Her goal with any team is to teach them to fish as fast as possible. And at times, she may be just a bit impatient and come across as not based in the real world. She has just been hired to be an embedded coach for Walter Fall. Given what she has heard about Walter, this should be an interesting time!
Now that you’ve met Walter and Sarah – Who do they remind you of?
Your Boss? Someone at your last job? You at your current job? Certainly, this is not about good versus evil. Both Walter and Sarah can learn from one another in terms of best practices and adoption paths; the realities of large scale adoption; the pain of moving from one’s comfort zone; and, the thrill of enabling teams to continually find pride in their work. And you can bet they will challenge one another.
Look for Walter and Sarah to pop up from time to time on our blog with their perspectives. We hope their interactions prove to be both fun and informative as you follow the progression of their Agile story.
About the Author: Jean Tabakais a wine enthusiast, an Author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts. That question is quickly followed by, “And I don’t want to hear that it works everywhere!”
Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”
Where To Start
Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.
Our rendition from "Stand Back and Deliver"
In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts. They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed. The variables used in the book include:
Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies
Three Perspectives
We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project. The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
Projects of Low Uncertainty and Low Complexity rank third. They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.
Environmental Factors
Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success. Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments. Here is a snippet of that kind of team assessment:
Does the Product Owner have the right level of authority and influence? Are they…
Embedded with team?
Dedicated to the project?
Able to gain consensus from stakeholders on goals and features?
Able to evolve the product backlog (with training)?
Able to support the team through constant feedback and decision-making?
The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
Architects might be contributing members, or might be advisory.
Is the team co-located?
It’s not required, but can be a risk factor.
For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.
Do you have an Uber Product Owner and Uber ScrumMaster?
For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.
Is there a controlled build environment?
To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).
You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach. To me, Agile works everywhere, it is just a question of how good do you want to be and by when.
RallyDev.com
Walter is well-meaning but may be just a bit stuck in an old school way of doing things (The guy still carries a comb just for his mustache for goodness sake!). He holds fast to the practices he has accumulated over the years and is happy with where his career has taken him. Walter has been with his company for 20 proud years and now runs a division of ~120 people, all organized in functional teams. Walter’s VP, a golf buddy, recently brought in a full-time consultant named Sarah Scrum to coach him and his group on adopting Agile practices. Walter is unamused, but he’s willing to listen, if only to prove her wrong.
Sarah is passionate about Agile. She seeks continuous improvement, almost annoyingly so. She loves a challenge and has found Agile to be a valuable resource for tackling technical and organizational challenges. Sarah has worked with Agile teams for the last 7 years leading them through maturing and scaling their Agile adoptions. Her goal with any team is to teach them to fish as fast as possible. And at times, she may be just a bit impatient and come across as not based in the real world. She has just been hired to be an embedded coach for Walter Fall. Given what she has heard about Walter, this should be an interesting time!
