Agile question of the month contest for January 2010

Time for another chance to win a $25 Amazon gift certificate.  This month’s theme is “Getting a Fresh Start” so the question is going to be about starting an agile project.  This question is simple, but has a lot of nuances which make a complete answer imperitive.  Remember, everyone is eligible no matter who they are, but also remember that I am the final arbiter and my decision is the one that counts.  Keep in mind that I am a Certified Scrum Coach so that will be my perspective.  As in the last contest I won’t be answering questions (much) and please list any assumptions I should make when reading your answer.  Please your answer in the comments section below so we can all see it.  Also use a real email address when leaving the comment since that address has to be valid in order to get the Amazon gift certificate.

January 2010 scenario:

A friend of yours is the VP of Software Development (highest ranking technical person in the company) at a small software company.  He has 9 people who work in his department including a Product Manager, Project Manager, Development Manager (who also codes) a QA Manager (who also tests), 4 developers and 1 tester.  Each person does an adequate job but your friend is a bit worried the Product Manager doesn’t really understand marketing and the QA Manager seems to always be at odds with the developers.  The newest team member is the Project Manager brought on board about 6 months ago.  The developers have all been with the company for a minimum of 2 years.  The tester is a very recent addition with only 4 months of experience with the team.  The QA and Development managers are long time employees of the company.  The Product Manager has been with the team for 2 years but was “promoted” from being a developer.  The team has worked extensively with Java but their next project will be done with Ruby on Rails.

Their development process is classical waterfall and they have all of the classic problems.  The last release was a total disaster being 6 months late on a 12 month project and exceeding budget by nearly 100%.  The company creates software which costs each client over $200,000.  The company has a small number of clients but the last project cost them 15% of their installed base.  At this point the CEO has made it very clear the next project needs to be successful or the company will be out of business.

The question:

Your friend has asked for your advice because he knows you are an agile advocate who has been successful with it.  He has about 4 weeks before the team needs to start the next project (they are waiting on some hardware upgrades before starting) and he wants to use that time to maximum advantage in getting the team ready to proceed with agile.  At the end of the 4th week the goal is to start working on a 6 month project to deliver a completely new module for their base software which will hopefully expand their potential client base into a new market.  Your friend doesn’t know much about agile, and no one on the team or in the rest of the company knows much about it either.  He feels strongly it is his only hope for real success and the team has agreed they need to try it.

How would you advise your friend to proceed over the next 4 weeks and during the 6 month project?

I am looking for answers which are as specific as possible because I anticipate many of the answers to this one being very similar.  It is a much easier scenario than last month, but this month’s theme is “Getting a Fresh Start” so this seems like a good question to start the year off!

This contest ends at 11:59pm Mountain Standard Time on January 31, 2010.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Bob,
    My first advice would be to find a coach with a good reputation, changes like this especially when the heat is on can be deadly if there is no voice of experience to help.
    Assuming they picked me the first thing I would do before I jumped down the Agile path was meet the team, Ideally getting the VP to put my visit in context and try to get them to see me as more of a concerned friend than the axe man. Then spend a short period getting to know their strengths and weaknesses, look at the corporate environment and try and sniff out some early road blocks especially the QA manager given their current relationship with the dev team.
    Assuming that the team members are not destructive and are to some extent supportive, I would start with some training.
    Weeks 1 – 4
    Week 1
    Get to know the team
    Get to know the corporate environment
    Understanding Scrum the process – doggy day care type exercises, getting the devs and testers to think for themselves, basics of product ownership and facilitative leadership for the PO and PM.
    Agile the lifestyle – Spend some time trying to cover what it really means to work in an Agile environment. I know this is not something you can learn in a day but it’s about using real world examples to highlight that Scrum is not a process you follow to be agile. For example the difference between a user story as a representation of the product owners needs and thus the sum of work for a project and it being the start of a very involved and evolving conversation which leads to analysis, design, build and test in a couple of days. This shift to being Agile rather than doing Agile would also focus on their technical practices and how we could shift towards TDD / BDD over time.

    In my opinion trying to get a team to successfully adopt:
    Scrum
    Agility
    TDD / BDD
    User stories
    Retrospectives
    Story points (you know the looks you get when you first start to explain these!)
    ETC
    Would be impossible in 3 weeks before the next project is due and I would be spending lots of time with the VP on this to manage his expectations and working with the team to plan what we can actually adopt and what we can slowly adopt. Assuming there is not an internal champion for TDD I would ask the VP for some additional funding to cover a resource for this as I feel it is an essential building block for successful Agile Implementations (unfortunately for me I am from the PM, team, people background rather than huge amounts of dev so i would need real knowledge in this area).

    Weeks 2 – 4
    My plan for the remaining time would be:
    Get the team to have some exposure to iterations by getting them to build a backlog to cover:
    The changes to the team, who is going to perform what roles how does testing work.
    What done means
    Environments
    TDD practice / pairing practice
    Writing User stories / acceptance tests
    How to test
    Corporate process changes etc
    Documentation changes etc
    Generating a backlog for the new project

    Once we have enough of a backlog in place I would help the team (PO, SM and Team) through sprint planning (weekly sprints just to get some practice in) and general daily life on an Agile project (through general coaching).

    During these 3 weeks my focus will be on empowering the team to remove the roadblocks and working with the product manager to help them understand product creation, work out their vision for the new project and the user roles and goals they hope to address by building it. Hopefully this will help get them focussed on product creation rather than thinking like a developer.
    Finally I would be spending time with the VP so that we can put in place some meaningful measures / milestones for the new project so that we can check-in and discuss how the team is getting on with the new practices and how that is affecting project success.

    Phew the four week blur has just zipped past and now we get into the real work.
    For the main 6 month project i would still recommend a coach for the team but their time would gradually decrease as the months went by.

    First Month
    Start the team on a 2 week iteration heart beat, i feel that 2 weeks is a better window to plan and organise your work over especially if you are new to Agile (you get to the retrospective quicker too).
    Sit with the teams and observe daily life, apply gentle nudges as needed and answer / mediate on any issues.
    Facilitate the first couple of retrospectives so that the scrum master can see how it is done and secondly and more importantly they can contribute to these early meetings without compromising their facilitator role.
    I would also have a retrospective for the management team to discuss how things were going from their point of view.
    Depending on the retro results I would see what the team could fix by themselves and then work with them and the TDD coach to fix the other issues.

    Second and Third Months
    Rather than being in daily i would come in every couple of days and observe practices, sit in on the major meetings (planning, demo, retro) and provide more of a hand off mentoring approach, working with specific team members. Towards the end of the third month I would also to start to introduce a new practice not yet implemented for example BDD.
    Final half of the project
    In this period I would visit once or twice a sprint and work on a specific practice with the team to really hone their skills, getting to grips with good story writing is a good place to start as it really helps the rest of the work practices.
    I would also work with the management team to address their needs and 3 months in we should really start to see that the major pain points have been addressed and if not I need to work with the VP to understand why.
    I also feel that this is about the time that people start to go back into old habits as the newness will have worn off. Coming in less frequently allows this to happen naturally (rather that the coach papering the cracks all of the time, i know it’s bad but i does happen) and makes for a more involved and focused meeting discussing why something was dropped.
    Finally over this period I would spend more time with the Scrum Master coaching and mentoring them to become the team coach as well as the facilitator.

    Thanks

    Mike

  2. As the company is small and has recently gone massively over budget on a projects I’ll assume that they don’t have much of a battle chest remaining and cannot afford much in the way or outside assistance, so this will be geared towards allowing them get themselves running as well as possible.

    If they have funds available I would suggest a consultant would be most useful in the initial 3 days of this plan and at the first release retrospective.

    I would suggest the team spend roughly two days familiarising themselves with agile processes: reading the literature, dicussing what they feel comfortable with etc.

    They should then move directly into a month long release, where they prototype as much functionality as possible, featuring two nine day sprints. This would be done on the understanding that all code would be thrown out at the end, but a normal set of demos(these must feature working code) did have to take place.

    There are a number of things that will happen during this month that will be invaluable to the team.

    To deal with quality concerns it would be reasonable to require a certain level of test coverage throughout the process(The team should decide what this level is). The time limits of the sprints will necessitate shortening the feedback loop between QA and Developers, hopefully this will help with removing the difficulties between them. If not, it may be necessary to examine the relationship for interpersonal difficulties.

    They learn about the scrum process, ironing out plenty of kinks and getting a feel for how they can work inside of the process. Anyone who has issues with the move from waterfall can be identified and helped to overcome their problems early. Hopefully the results of successful prototyping can offset their concerns.

    The prototype release is also an opportunity to gain familiarity with rails and a better understanding of where the project will lead. The devs will benefit a lot from the extra time working with practical code before the start of the project and we avoid the horrible case of having to build the rest of the application on top of poor beginner code.

    By the end of the 4 week period the team has had two retrospectives and should have started to relax into the agile process. The second retrospective should be treated as a release retrospective and include significant discussion regarding how well the team is adapting to the process.

    A possible concern around this stage is if the “managers” who a doubling in programming or testing positions are dominating the team discussion too much they’ll be detrimental to the empowerment of the team. They may need to work on acting more as part of the team instead.

    The team will now start the 6 month process with significantly more experience in scrum and rails, and with a better understanding of the functionality needed by the module. The focus now will be on improving technique and stream lining the process over the following 6 months.

    I would suggest the team aim for two three month release cycles of six two week sprints to give them a consistent working speed and good goals that include a relase in time to gather plenty of beta user feedback before the end of the project.

    Retrospectives will be particularly important for the first few sprints as large corrections in development strategy are likely to still be occurring as the team becomes more comfortable with wanting to try new methods.

    From here maintaining the scrum focus is the major problem. Keeping the team focused on done each sprint will be of particular importance. The company cannot afford to have bits of work slipping again.

  3. Derek,
    Surely all the best companies have a 1:1 ration of managers to subordinates? I would love to have a manager looking over my shoulder all of the time, it would make me feel valued and needed. =8-(

  4. Much more briefly; I would start by identifying their pain points to get as raw feedback as possible. Then introduce Agile principles. Principles being key. Then, pick tools from the various methodologies (maybe standups are appropriate, maybe they already DO peer programming, maybe they are so dispersed that a true standup is not possible, etc.,) that can alleviate pain points and come up with a plan to make a more structured and more Agile process as time goes on. Certainly, I would not involve the Agile CMMI, but my motto has been “head in the right direction and you’ll get there.”

    I don’t think you can make a company a fully functioning Agile shope in that amount of time, and it is only theory until you use it, but you can teach a man to fish and then send him to a river… once he grabs a trout, he will be hooked. How’s that for a metaphor?

    And, of course, Monitoring and Controlling after they get started 😉

    (Yes, a deliberate dig at PMI)

    Best,

    Josh

  5. The first premise to work with is that this friend has asked me, so the question of how much $$ the company has to spend on a consultant may or may not be an issue, depending on whether or not I’ll be in a position to help him much for free. Telling him to go hire someone else seems counter-productive for a few reasons and having a very big “plan” early on seems wasteful until I understand what’s going on.

    So I’ll assume I’m going to help him as much as I can. But to be willing to do that, I’d want to get to talk to my friend and the other 9 folks to see what they (a) think the problems might be and (b) might be willing to do to address them. I’d want to get this done the first day. The second day I’d ask them all to sit in on a presentation of the Agile Values and Principles, take a self-assessment I use (to understand their readiness to pursue an Agile approach), then (after lunch that day) regroup to see their assessment results and talk about a possible plan forward with them.

    I wouldn’t presume to be able to know what to expect them to do or, more importantly, whether Agile is right for them just because my friend might like the idea. If it is true that the results of the next 6 months could sink the whole company, experimenting too much with what people know could hurt more than help. Also, changing technical platforms — hardware upgrade(s) and a new programming language & environment — is a major risk element.

    There are lots of things that could be planned in terms of training, practice iterations, etc., but big plans don’t seem to make sense until I learned what I could from these first two days.

  6. Wow, once again some awesome answers. I like a lot of what I’ve read and I am very torn on who should win this month’s contest. In the end I had a few things I wanted to see in answers which I could consider as the winner:

    1. Don’t have a plan that was too long. Having a plan for the entire 7 months is probably not a reality. Things will change too much.
    2. Some way to assess the team and give meaningful feedback for how to proceed.
    3. Understanding there are significant dynamics at play which could cause the whole thing to blow up.
    4. An answer which was unique in some fashion. One that would make me say “Hmmm…”

    Let me say that all of the answers given could probably work as long as implementation was kept lightweight and open to change. I like that everyone took time to write answers which reflect their beliefs. I actually learned a lot from reading each one.

    In the end though, one answer stood out. This month’s winner is:

    Breccan McLeod-Lundy

    I found myself thinking “Hmmm….” when reading that answer. I really liked the concept of taking the first 4 weeks to practice agile. Don’t just learn about it, but do it and adapt to what you learn. It also would allow for changes if the team just isn’t capable of doing agile right away or if other significant risks were exposed.

    Congratulations Breccan!

Bob Hartman

Known as Agile Bob, brings over 30 years of experience and broad industry knowledge cultivated by serving in almost every role in the software industry including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager and executive. Over the past 15 years Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer® (CST) and Certified Enterprise Coach℠ (CEC) and an expert in training, coaching and mentoring across all areas of Agile development. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops and user group meetings where his engaging style, holistic view of development and personal anecdotes are always well received by attendees.

Connect

bob.hartman@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author