Lessons Learned from Integrating Agile via Scrum
You may recall a post titled “Software Implementation Nirvana” which dealt with the common pitfalls associated with full life cycle development or SDLC (akaWaterfall). Agree or disagree with my position, it is clear that organizations and groups are adopting “lean” development techniques such as Scrum. According to the Agile Alliance adoption of Agile frameworks within organizations has increased by 24% over the past year and a record number of participants have attended user conferences, up 45% since 2006. Fad? Maybe, but I believe there is more to it. Though I’m partial and believe in Agile/Scrum and have seen it in motion, this post will hopefully help you navigate the waters if you’re thinking about implementing. I wish I would have known some of these before I got started.
Lesson 1 - Scrum is a state of mind.
Your either republican or democrat. You eat meat or you don’t. You like cats or hate them (I hate them). You accept Scrum or you don’t. Scrum isn’t for everyone. I’ll say that again, it’s not for everyone. If you’re used to rigid process and everything being completed at the end, it’s not for you. If you’re working in a regulatory environment, it’s probably not for you. If you’ve got a mix of believers and non-believers, proceed with caution. Nothing brings down the adoption of Scrum into an environment more quickly than the “negative voice”. If those negative voices exist, you will be challenged to implement however not totally crippled. What you need to do is get alignment. Agree or disagree with the voices, if people don’t have an opportunity to buy into the process then they will never believe therefore causing noisy chatter during the process. Make sure you include the biggest nay sayers in all the discussion and make it a point to ensure their voice is publicly heard. Needless to say don’t forget to get that all important executive buy in. If influential juggernauts are not pushing the initiative from top down, you’re doomed regardless of the intentions within the team.
Lesson 2 – To off shore or not?
This question is like asking my son…”Do you want ice cream?” Regardless on how I phrase the question, the answer is yes. I think the questions we should really be asking re:off shoring are a) how you prepare to offshore and b) what roles need to be onshore? If you’re in corporate America, you know there is a trend to save costs which usually equates to off shoring resources. Regardless of your opinion on the matter and regardless of your previous experiences with off shoring you’ll have to learn to deal with communication barriers that exist when dealing with an offshore team if you try to implement Scrum. A few things to remember, patience, don’t degrade, people at your level even thought they don’t make as much money. Treat them with respect and with patience and you will reap the rewards. Learn the culture. If you’re working with and off shore team in India, there’s a whole cast system the pervades the team regardless of role. Take a moment to understand. Also you’ll have to realize to get effective leadership you will most likely have to use a management team onshore. But I’ve seen some odd decisions when people are trying to save money.
Lesson 3 – Does this Sprint look long on me?
Conventional wisdom and all the experts dictate that iteration (aka sprint) should not exceed 4 weeks. In general this is the case, but if you’re Product Owner is plugged in and has context, and the programmers are flying, let them get as much done as possible. The dividends for more accurate functionality will typically outweigh your progress translated out of context from a burndown chart. Key here is making sure the Project Manager keeps all parties aligned and informed.
Lesson 4 – Scrum off the shelf
Just to clarify that Scrum is a project management philosophy within the Agile philosophy. As I said Agile and Scrum are a state of mind. Scrum has roots in lean process management therefore Scrum adapts and adopts continuous improvement within itself. The core tenants of Scrum allow for change in process as long as teams collaborate. Said differently, you don’t have to change it, Scrum will most likely adopt to you.
Lesson 5 – Do we still need testers during Scrum?
Most Agile experts will dictate that test driven development (TDD) is the way to go when testing Scrum projects.. I happen to agree but with 2 caveats. First the programming team should adopt some type of XP skillset (ie Pair Programming). Second there should be a regression testing suite such as the xUnit family. Don’t forget all the scripts for previous development! If you’re shop is like most, the 2 caveats are not reality. A solution to this lack Scrum governance is to adopt some type of derivative of TDD that works for you. The key is to have a strategy on how to perform regression tests, because if you’re moving at a high velocity, the amount of time to regression test is just not built into the sprint. And let’s not forget unit testing. Unit testing is also key to Scrum testing.
Lesson 6 – Psychotic Project Management
Project managers will make or break your Scrum development initiative. A Scrum Master’s (aka Project Manager) role doesn’t change much from a traditional one. They are there to facilitate things and make sure impediments are removed. The key change here is how the project manager tracks progress via burndown charts etc. Lesson learned here, all project managers are not the same. A tactical manager used to plugging in numbers into spreadsheets is not the breed you need for Scrum. You need dynamic thinkers and leaders.
Lesson 7 – Garbage in = Garbage out
Many people tell me those systems developed using Scrum are not scalable b/c no forethought is put into the architecture. I simply respond, if you have good developers it systems developed using Scrum are. Doesn’t matter how good your processes are, if people who developed them cant make it object oriented and scalable, the process will not be scalable thus business clients will not see the value long term value. Simply said bad programmers create bad code.
Lesson 8 – Were you successful?
Success will be measured by your performance objectives which typically are measured by the “Requirements Burndown”. If a team has completed all the requirements within an iteration why wouldn’t they be successful. Don’t get caught up in the budget debate, because the amount resources cost are typically constant.
Lesson 9 – Retrospective isn’t just a buzz word
One of the simplistic beauties of Scrum is the ability not only to realize what continuous improvement is, but adopt learnings almost immediately after the completion of a sprint. Given the teams are self managing; it’s a wonderful thing to see improvements come to life in subsequent sprints. It’s almost as everyone on the team understands the context of the improvements and the approach the team members are taking. This part of the process is my favorite as it’s like a marriage, it gets better with time. Just like those of you who have a significant other and can read their mind so to speak, the same begins to happen after the retrospectives thus creating a channel for continuous improvement
About the author –
Hassan Mahmud is an Principal of WEKGroup, LLC a project and management consultancy specializing in forward thinking and technology adoption within the pharmaceutical industry. He is an early adopter of lean process management and has implemented Scrum on dozens of projects and provides coaching services for organizations investigating the implementation of Scrum by providing coaching services. For more information on Mahmud and WEKGroup’s services, you can visit them online.
No comments:
Post a Comment