Since we celebrate the signing of the Declaration of Independence on the 4th of July, I thought it was a good time to look at another declaration related to the agile space. In 2005 a group of leaders in the agile space (Jim Highsmith, David Anderson, Mike Cohn, Christopher Avery, Todd Little, Pollyanna Pixton, Doug Decarlo, Donna Fitzgerald, and Lowell Lindstrom) got together to form what is now known as the Agile Leadership Network. They created the Declaration of Interdependence “to serve as guiding principles to employ Agile and adaptive approaches for linking people, projects and value.” [click to continue…]
employees and employers should agree upon short increments of work to accomplish together much like a military tour of duty. Once the work is complete, they should meet to reevaluate what happens next.
Keeping with our theme of independence for the week, this is a good interview with Reid Hoffman on the subject of employee’s independence from the old school “lifetime employment” model.
Reid describes a very interesting model of employment. It seems to fit really well with agile values, it’s definitely a highly transparent model that would require trust. In it managers work with employees to better define how they will work together to meet the needs of the company, while at the same time advancing the employee and meeting her needs towards her career goals. [click to continue…]
By nudging employees to take real vacations — vacations where they’re genuinely inaccessible — he’s built a culture that can’t depend too heavily on one person for any particular thing.
Looking to gain more independence from your job? This is an interesting perk that has had the great side effect of ensuring there are no single points of failure. I’ve struggled with the “hero mentality” in many jobs. I’ve even suggested companies take away individuals computers, forcing them to work with other people to help get cross training where the hero mentality has ruled. Trying to be agile in an environment that has a lot of hero mentality is really hard. Agile takes teamwork, and trust. Those are often hard to build up with someone suffering from hero mentality and even worse if leadership is awarding hero behavior as that discourages teamwork. I think it would be great if more companies would adopt a policy like this. Avoiding single points of failure is only one of the many benefits, the article talks about several more. Enjoy!
Self-organizing teams are not teams gone mad. Like all teams, they need a compelling goal, skills, information, and enough time to form and perform. And they still need managers to create a supportive context, set appropriate boundaries and constraints and connect the team to the organization.
There is a lot of talk about self-organizing teams and empowering the team. This can often lead to misconceptions, specifically that teams are completely independent. There is a lot of concern and misunderstanding about if managers are needed in agile and what they do. This article from Esther Derby does a good job of listing a few of these misconceptions and pointing out how managers still play a key role in agile organizations.
When teams are forced to use complicated taxonomies for their stories, they spend time worrying about whether a particular story is an epic, a saga or merely a headline. That discussion is like the minor character who walks into the novel and needlessly complicates the plot.
Thanks for reinforcing this Mike. I’ve been telling my teams this for years. A story is a story. Some are big and will need to be broken down, but they are still stories. I personally don’t even like the distinction between a bug/defect and a story. It’s all work that needs to be prioritized, discussed, and potentially brought into a sprint. I’ve seen way too much time wasted arguing over if something was a defect or an enhancement request. It really doesn’t matter.
It’s not so much about sketching per se. It’s about moving agile teams forward and getting to decisions faster.
This is a good interview with a UX consultant about how useful sketching can be as a facilitation tool.
I always try to use sketching in grooming meetings and it has always helped move things along. When we are just discussing we spend a lot of time trying to get on the same page. In fact, even when we are on the same page we spend a decent amount of time trying to validate that we are on the same page. With sketching, that happens instantly. Whoever is sketching is putting their interpretation on the board and everyone else instantly knows if that’s what they were expecting or not and that drives the conversation. We all walk away with a much better shared understanding. Even if we aren’t working on a UI, sketching processes, classes, databases, it all helps get everyone on the same page.
I also want to point out the importance of the low-fidelity of the sketch. I’ve struggled a few times working with designers who come back with high fidelity mock-ups. Often times, when the team sees something that looks like a finished product, they assume that all the details have been worked out and are final. They look final, so everything must have already been considered, discussed, and decided. Often, that really isn’t the case. When we start with a low fidelity sketch, everyone knows it’s not final. It’s not exact, but it points us in the direction. We can finalize the details as we go and as we have discussions. It gets us back to the Conversation over Documentation value.
I think that all of the scaling hoopla is just that. I don’t believe we have a distributed team problem or a scaling problem in today’s small or large-scale agile contexts. And huge applications don’t need to be built by 10-50 Scrum teams.
We have an un-scaling problem. We have a boiling the ocean problem. We have a trying to throw too many people at it problem. We have a love of size and scope problem.
Great post Bob! There is a great deal to be said about keeping things simple. Most companies seem to want to be everything to everyone so they end up being a mediocre solution across the board, at best. Pick a focus and knock it out of the park. Once you’ve knocked it out of the park then consider expanding your focus or moving on to a different focus.
I think another problem, and part of the appeal of some of the big scaling frameworks, is that people want a checklist. They want to be told exactly what to do. They don’t like hearing that it depends on the team and the problem and there is no single right answer. SAFe and DAD and the like seem to be showing a single right answer so they jump at it. I’ve seen this attitude many times from both leadership and team members. On the team member side they are often so beaten down from command and control environments that they are scared to take a chance and make a mistake, so it’s more of a CYA move. The same is even true at the leadership level. It feels similar to the old saying “No one ever gets fired for buying IBM”.
I tend to agree with Bob, SAFe and DAD aren’t inherently bad. They have good practices and ideas, however they are easily misused. It’s easy to just treat them like a checklist and forget about all the agile values and principles. That’s where the danger lies. Though I guess the same can be said for Scrum. We’ve all seen plenty of teams going through the motions of Scrum that definitely are not being agile.
User Stories use a card so we can’t write down too much, which forces us to have a conversation. That way, we are much more likely to have a common understanding of what is needed.
My first contribution to the Fusion Alliance Blog was published today! I am planning to make some regular posts similar to this one that are fairly short and simple but provide some explanation and example as to why agile teams do certain things that are often misunderstood. There is a lot of misunderstanding around documentation in agile. Agile is not anti-documentation, however it is pro-conversation. This post gives an example to help support why agile focuses more on conversations than documentation. I hope you enjoy it!
If we unpack the reasoning behind why teams might wish to make sprints longer, certain anti-patterns tend to emerge. Anti-pattern 1: Teams are spending too much time preparing for sprint reviews/demos. Anti-pattern 2: Teams are attempting to complete stories that are too large. Anti-pattern 3: Teams are running “mini-Waterfall” sprints. Anti-pattern 4: Teams encounter problems with code merges, integrations, and deployments. Anti-pattern 5: Teams are relying heavily on individuals external to the team to ge
This article does a pretty good job at showing some of the common reasons teams say they want to have longer sprints and also showing why longer sprints won’t help. Generally speaking, if you are struggling to get stories done at the end of the sprint, you should shorten your sprint until you can be consistent. Once you are consistently getting done everything you said you would at the start of the sprint, you can make it longer again if it makes sense.
There are often systematic reasons keeping you from getting stories done in a sprint and having more time generally won’t help those. However, having more time will allow you a bigger buffer to ignore those problems. A shorter sprint length makes it harder to ignore those problems and thus they become more obvious, making it more likely that you will see them and fix them.
transparency — visualizing the workflow — is a crucial step in harnessing the power of agility and minimizing chaos in our lives. And this step alone creates a huge win for anyone who will use it to inspect and adapt.
I’ve seen several posts on the subject of Agile at Home recently and I’m very interested in trying it out. I thought the story about the budget discussion from this article was particularly interesting. There is also a good TED talk on the subject from Bruce Feiler.
So on this Friday afternoon heading into the weekend away from work and with your family, think about how agile practices could improve your family life. Enjoy your weekend!