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.