Agile Mashup

Orlando Scrum Gathering – I’m going to be a doctor soon!

Bob Hartman — Tue, 09 Mar 2010 20:07:54 +0000

In about 5 minutes I’m going to play the role of being a “doctor” at the Scrum Clinic which is part of the Orlando Scrum Gathering. It’s an interesting concept. A doctor and a patient meet to discuss a topic important to the patient. In my case the patient wants to talk about the Scrum Alliance Certified Scrum Coach (CSC) program. Since I am a CSC and all of my CSC brethren wimped out I’ll be the one acting as doctor. I’m looking forward to it so I’m only kidding about the rest of them wimping out!

More on the Scrum Gathering later this week. It’s bee great so far!

Related posts:

I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or…
New to agile? Watch an Intro to Scrum video in about 8 minutes My friend, Arif Gangji, and I created this video to help his…
Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too…

Nine Questions to Assess Team Structure

Mike Cohn — Tue, 09 Mar 2010 15:53:19 +0000

It is perhaps a myth, but an enduring one, that people and their pets resemble one another. The same has been said of products and the teams that build them. If it is true that a product reflects the structure of the team that built it, then an important decision for any Scrum project is how to organize individuals into teams. This paper presents a set of guidelines to consider in designing an appropriate team structure. Each guideline is presented in the form of a question to be asked of a current or proposed team. The questions are intended to be asked iteratively. Ask each question of a current or proposed team, changing the structure as appropriate based on the answer. As the structure changes, re-ask the questions until you can answer “yes” to each.

Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? People don’t enjoy being on a team where they are not able to make use of their strengths or are constantly required to do things they are bad at. Good team members are willing to do whatever is necessary for the success of the project, but that doesn’t relieve us from the goal of trying to find a team structure that accentuates the strengths of as many team members as possible.
Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? A well-conceived team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If more than 20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
Does the structure maximize the amount of time that teams will remain together?
If other factors are equal, you should favor a design that allows team membership to persist over a longer period. It takes time for individuals to learn to work well together. Amortize the cost of that learning over a longer period by trying to leave teams together as long as possible.
Are component teams used only in limited and easily justifiable cases? Most teams should be created around the end-to-end delivery of working features. In some cases, it is acceptable to have a component team developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have five to nine members.
Does the structure minimize the number of communication paths between teams? A poor team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams. Some inter-team coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, as I’ve seen, then the communication overhead is too high.
Does the structure encourage teams to communicate who wouldn’t otherwise do so? Some teams will just naturally communicate with each other. An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord. In fact, one valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person’s time between those two teams is easily justified.
Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities.
Did team members have input into the design of the team? During the early stages of your transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint. Similarly, some individuals may be initially too resistant to Scrum to contribute to team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial team structure.

An effective team structure is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems. By using these nine questions to carefully consider how teams are organized you can avoid these problems.

New Tools for Prioritizing Backlogs Available

Mike Cohn — Mon, 08 Mar 2010 14:37:14 +0000

We’ve added two new tools for prioritizing a product backlog: Theme Screening and Theme Scoring. Each of these is a lightweight way of comparing product backlog items to one another.

Theme Scoring

You can use theme scoring to compare user stories or entire projects against one another. In this technique you identify a set of criteria that will be important in prioritizing. Each item is assessed on a relative 1-5 scale against each criterion and the priorities are determined.

Theme Screening

Like theme scoring and relative weighting, this technique can be used to prioritize user stories or projects against one another. The simplest of the three prioritization techniques, theme screening starts with you identifying a baseline item. Each other item to be prioritized is compared to the baseline item for a set of factors that will determine priorities.

Excuses Might Be the Response, Not Necessarily Resistance

Jason Little — Fri, 05 Mar 2010 17:41:27 +0000

I had an interesting conversation with a manager the other day about how to gain more insight into changes that are ongoing in the application one of our pilot Scrum teams is working on. First, what’s the problem? Group A was doing independent regression for a release and uncovered some ”defects’ that were a result of changes in the application by our Scrum team. Truth be told, those ‘defects’ are actually de-commissioned functionality.

Manager: We need to know what’s being changed in the application, we can’t be chasing down defects because of changes we don’t know about.

Me: Agreed. We’ve extended the offer for you to come to our end of iteration demos and until this week we haven’t made any changes in existing code so I agree, with these changes we’ll have to invalidate some of the old regression tests that aren’t needed anymore.

Manager: I don’t have time for that. Is there some type of documentation about the changes?

Me: Yes. We’ve started using javadocs to document the code and our functional information is in Rally. Brief, but explains the functionality well enough. The team members would easily be able to figure out the impact of the changes since they all know the app well enough.

Manager: I can’t ask my team to waste time sorting through Rally to find this information.

Me: We can export a list for you and email it, it’s a 4 or 5 column XLS with a good summary.

Manager: Do you know how much email we get? I can’t agree to that.

Me: Ok, how about you and the members of the other groups who need insight into the changes come to our demos? We do a 15-minute quick overview before digging deep into the stories we completed.

Manager: They can’t do that, we don’t have approval from their managers to go to your demo.

Me: Ok, we do send a summary of what’s being updated when we make our iteration commitment and we send a summary output after the iteration demo, I can include you on those.

Manager: There’s too much to do, I have to worry about this project, that release, aligning this team with that team, I get too much email now, we need a process.

Me: Ok, so how about we just have the people from the other groups attend our demo, we’ll give them the 15-minute overview and send the summary of changes before and after the iteration. If we need to do a more in-depth session, we’re happy to.

Manager: I’ll go talk to the managers to get permission for the other resources to go to the demo.

Me: Great, that should make it easier and really efficient to share information between our Scrum team and the waterfall and regression teams. Thanks!

At the end of the conversation we were right back to where we started. A quick and efficient session to share knowledge with the people who are programming or testing the software. I had continued this conversation with a few folks to get to the real problem and the challenges being faces are typical.

So what’s up with all the excuses? Did we have to fill up the 30 minute time-slot for the meeting to be effective? I decided to dig deeper:

Q1) Why was the initial response that people couldn’t spare 15 minutes every 2 weeks to get visibility?

A1) Because we are too busy.

Q2) Why are we too too busy?

A2) Because regression testing takes 3 weeks.

Q3) Why does regression testing take 3 weeks?

A3) Because our testing is manual.

Q4) Why is our testing manual?

A4) Because that’s how we do it.

Q5) Why do we choose to do it that way?

A5) Because there are too many projects and we don’t have time to do it another way

I’m sure there were a couple more excuses tossed into that first conversation, I started losing count but the underlying problem of having too many projects in progress at a time are causing a whole host of downstream problems.

At this stage, portfolio management isn’t something we can focus on, especially in a large and complex organization. First step is to create visibility to outside teams and trim down the regression suite so there is less waste with manual testing. Our team has already started looking at automating end-to-end regression for happy path scenarios which will also reduce the amount of time spent on manual testing.

It’s a small step, but we need to start somewhere but the message in this post is that things aren’t always as they seem. The initial response is often a gut-reaction based on stress or other factors and it shouldn’t be confused with resistance to improvement or efficiency gain.

Agile Central Europe Conference Schedule Announced

The Agile News — Fri, 05 Mar 2010 14:25:02 +0000

The conference schedule for Agile Central Europe includes two full tracks and an open space, with talks ranging from agile retrospectives to kanban. [Read more about the conference][1].

[1]: http://blog.adsdevshop.com/2010/03/05/agile-central-europe-conference-schedule-announced/

Great Article on Shu-Ha-Ri

admin — Fri, 05 Mar 2010 03:38:51 +0000

Christian Gruber, a Googler, an agile guru and an Aikido practitioner clears up some important mis-understandings about Shu-Ha-Ri as applied to both learning Agile and learning Aikido: http://bit.ly/bqgvZS . Strongly Recommended!

DevOps – Extending Agile To Deployment And Operations

The Agile News — Thu, 04 Mar 2010 14:15:10 +0000

Agile ideas are making their way into IT groups and data center operations, enabling greater business agility. Learn more about [extending Agile to deployment and operations][1].

[1]: http://blog.adsdevshop.com/2010/03/04/devops-extending-agile-to-deployment-and-operations/

Agile Coach Camp, North Carolina, March 19-21

Mike Cottmeyer — Wed, 03 Mar 2010 19:36:00 +0000

Are you registered for the Agile Coaches Camp this month in Durham, NC? If not, you should. I’ll admit… I was a bit skeptical about the first Agile Coach Camp in Ann Arbor. The guys at VersionOne asked me if I wanted to go. I was like… fly to Michigan… on a weekend… with no agenda… no speakers… we all just get together and figure it out? Sounded like a train wreck to me, but for some reason, I went anyway.

Needless to say, I had never been to an Open Space conference…

I learned that there is something very powerful about being a room full of passionate people that are trying to make the world of software development a better place. It was a pretty amazing experience… some of the closest relationships I have in the agile community were formed at the last Agile Coach Camp. Nothing like a couple of late nights, talking about agile stuff while smoking cigars and drinking martini’s, to bond a group of strangers together!

Head over the the AgileCoachCamp Wiki for more information about the camp and links to register. I have no doubt this camp will be as powerful as the last one. Seriously… you gotta be there… I’ll be there… go… register now!

New to agile? Watch an Intro to Scrum video in about 8 minutes

Bob Hartman — Wed, 03 Mar 2010 18:15:10 +0000

My friend, Arif Gangji, and I created this video to help his customers understand why his company uses Scrum as their software development framework. I decided I really liked the video, so I’m posting it here as well. It isn’t perfect, but it is plenty good enough to get across the basic ideas of Scrum. Over time it will probably show up in a few more places on the main website, but for now, enjoy!

Click here to view the embedded video.

I’d love to make our next video even better so if you have suggestions please put them in the comments below. Thanks!

Until next time I’ll be Making Agile a Reality^® by pointing people to this video for some introductory information about Scrum.

Related posts:

I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or…
Orlando Scrum Gathering – I’m going to be a doctor soon! In about 5 minutes I’m going to play the role of being…
New to agile? Work at a sustainable pace Question: Which is better: a) Working nights and weekends to meet iteration…

You Have My Permission to Not “Be Agile”

The Agile News — Tue, 02 Mar 2010 12:48:58 +0000

Blind devotion to Agile methodologies without taking the business’ context into account is causing major failures in companies. Agile methods such as Scrum and Kanban are flexible systems that can be tailored to help solve business problems. But if not being blindly devoted to the one true way means that you aren’t “being Agile,” then [you have my permission to not be][1].

[1]: http://blog.adsdevshop.com/2010/03/02/you-have-my-permission-to-not-be-agile/