Ative at Work

Agile software development

Ative at Work

august 2007 - Posts

  • Implementing Scrum in the Enterprise - Agile 2007 Day Four

    Ken Schwaber has been working on enterprise-wide Scrum implementations recently. In his session today he shared his experiences and offered a roadmap for the process.

    First off all there is no "Enterprise Scrum" - it is the same simple, empirical framework for developing complex systems that is applied everywhere rather than just in software development.

    This means that even senior management will also be working iteratively with a backlog and showing demonstrable results at the end of every iteration. This in turn, means radical transparency through the whole organisation at all levels.

    In Schwaber's experience the enterprise-wide roll-out of Scrum take some time. He offered the case of a 1000-developer organisation. Here, they spent six months on the roll-out (training everybody in the Scrum practices) and after that 3-5 years to implement it make it stick by iteratively removing the impediments to producing quality software in the organisation. As he said, "Culture eats strategy for breakfast", so this phase is all about changing people's habits and getting the waste out of the system. During this implementation a senior management executive Scrum team is in place using Scrum to deal with the impediments and demonstrably solve the top issues as they become visible during the transition.

    There is no "Done" - once the Scrum framework is implemented the organisation is in a state of continuous improvement, reflecting on its changing environment and evolving to stay ahead of the game.

    He offered this road-map:

    First, do a pilot project to learn the Scrum basics, then try Scrum on the most challenging, critical project in the organisation to make a proven case for everybody that is works.

    Then do the enterprise roll-out. This is where it becomes top-down and is implemented at all levels.

    Here is how the executive team works:

    First, create a backlog of what is wrong today - what is in the way of developing quality software (eg. "we have too many projects", "we don't integrate often so we have no visible status", "we produce too many lose ends"). Then commit to fixing it and use the Scrum process to fix it - first things first. Senior management has to demonstrably fix the top issue or issues in one iteration. Then attack the next top one, etc. etc.

    Meanwhile, the Scrum training for the entire organisation starts. This is the roll-out.

    For all the work, the Scrum team (max 9 people) is the basic building block, and Scrum-of-Scrums is use for hierarchical breakdown of the organisation.

    The benefits is a very visible status in the entire organisation, that it is all working from a single backlog and aligned with creating business value rather than some arbitrary and sometimes detrimental performance metrics (Jim Highsmith did a talk on agile performance management at the conference with some very good findings on this topic). There will be a very simple and open control structure encouraging an open environment over command and control - no need for additional committees and boards to control things at an often too late time.

  • Corporate Judo - Guerilla Tactics For Agile Transformation - Agile 2007 Day Three

    Today, we did a Discovery Session at Agile 2007. The topic? How do we implement agile. We worked in five teams that each created a roadmap for implementing agile based on their experience and their role in the organisation: management, team and customer.

    A big thank you goes out to everyone who participated. Please add your comment and notes to this blog entry.

    Michelle K. Cole, VP of Operations at ENVISAGE Technologies kindly wrote up the findings from the five teams as they presented. Here they are.

    Where Should a Manager Start?

    • get executive sponsorship
    • create vision & trust
    • education about benefits of agile
    • create common language and measurements
    • show value to team (what’s in it for me), benefits to the projects
    • provide a supportive environment
    • figure out success factors
    • set up agile advocate group
    • identifying if you need external coaches
    • establish team maturity model
    • staffing – hire those people that might be good in this environment (you might even need to fire some if there is too much resistance).
    • empower them to come up with a better solution
    • create a system of custom ownership
    • use peer pressure to bring other people along

    The other Management team offered this approach: 

    • do a big kick-off event
    • send key people to conferences like Agile 2007 etc.
    • provide readers/skeptics with books - some people learn well from books and many techies like to read a lot.
    • pilot a project & praise success
    • encourage culture of trying things
    • meet with individuals to understand pain points and processes to keep
    • Establish brown bags/training for people that like that style
    • Rearrange workspace so team sits together

    Guerilla Tactics for Teams - Developers/Project Managers/QA

    • how to overcome resistance to sitting in team room
      • have stand up in team room and don't let them leave afterwards!
    • how to get space for collocation
      • squatting long term
      • have stand up outside mgmt office
      • furniture on wheels
      • midnight runs
    • resistance to pairing
      • o stealth pairing (ask people to help another)
      • o set up a pair station
      • o coolest equipment in the pairing machines
      • o have appropriate hardware to pair (2 keyboards, two monitors, movable desks)
    • resistance to collaboration
      • make sure there are common goals
    • resistance to agile
      • convince the cool kid it is cool
      • explain there isn’t that much change
      • bust the myths
    • mandated process
      • ask forgiveness
    • resistance to TDD & automated tests
      • demonstrating the usefulness
      • pair with fans of TDD
    • involve QA
      • have the business analysts work with QA on acceptance tests
    • PM resistance
      • Show other non-software projects
      • Shadow existing projects
      • Send the PM on vacation


    Also from a Team perspective

    • Agile is not binary; it is a continuum.  You are someplace.  Where do you want to be tomorrow?
    • Change should not be inflicted upon people.  You should figure out what you can do and start to make that change.
    • As a developer, start doing TDD.
    • As a team, start doing stand up.
    • Agile provides many benefits.  Figure out which benefit you are trying to achieve most and start with the following:
      • Focus on Feedback - Fix length iterations with retrospective
      • If you need Flexibility - TDD is a good practise
      • Communication Issues are addressed Daily stand ups

    Customer team

    This was a very interesting team. Most of the people in the session had experienced resistance to implementing agile. The people from Yahoo, however, had not - for their two teams they just did a team meeting, introduced the agile practises and since the teams liked it they decided to do it.  Unlike most of the other people in the session they were completely self-organising and met no resistance to the change from their team, the management or the rest of the organisation.

    The group presented some suggestions for going agile

    • Get trained together to improve buy in
    • Be where the developers are; wait for them to ask questions
    • Us v. them – start doing things together as a team, may want to get an outsider to help build trust
    • Define product backlog & prioritize

    Other Ideas

    Doing Agile with Outsourcing

    • Use Scrum of scrums to synch the teams and beware of time-zone issues.
    • Have people go to other locations for a while to build trust and improve collaboration.
    • Find a balance of documentation – increase to improve communication.

    Partial change - do it gradually (actually, other cases like the experience report we mentioned the other day advocates going all-in).

    Survey people on what they need and fix it - it is often small things that make a big difference

    • If the rooms feel to sterile let people hang personal items from ceiling (eg pictures)
    • Add plants

    Empowerment based on company directives

    Room inversion

    • Switch to work in conference rooms and use offices for personal time (eg. phone calls).

  • Impressions From Agile 2007 - Day Two

    Dave Thomas told about his experience with large-scale agile projects. His take on plans:

    The Plan is really just The Best Wrong Answer

    Having said that however, he also noted that he had a very good track record with hitting the shipping dates - the worst project was Visual Age for Java which was three weeks late. His secret? Letting the team own the plan and doing estimates in ranges (wideband delphi) to prepare the planning session, then iteratively negotiating over the estimates until a consensus is reached.


    Release Engineering - Getting the Development Infrastructure Right

    Dave Thomas also named Release Engineering - the work to create the development infrastructure, automated builds and testing and providing dashboards with status for the project to be a key activity. In fact, his experience is that around 10% of the total effort should go into this area. The key points:

    • it is not something you outsource to the IT-department - instead, use real developers and co-locate them with the development team the first 3-4 months of the project as they work to set up configuration management, automated build, integration and testing.
    • Do focus on dependency management - you need to have thin slices of all the components with automated acceptance tests for the interfaces in place early so no-one is blocked by missing components.
    • All components should be tested independently - and provide acceptance tests for all interfaces.
    • Set up an automatic "Product Development Dashboard" with all the vital information - the goal is to eliminate the need for asking, "how's it going". This includes build status, test status, coverage etc. 


    Jim Highsmith did a nice presentation on agile from a management perspective, stating that the key to success with agile is to implement it throughout the enterprise. Doing it in silos is a suboptimisation.

    The key benefits of going agile:

    • it helps solve issues on developing features in a large, complex system.
    • it improves quality, and
    • it improves predictability

    The big value in agile is all the things you don't do.

    • not wasting time on the features you don't need (most features aren't used anyway).
    • the value is driven by the business needs, not by some arbitrary priorities.

    The essence - from John Wooden: "Be Quick, But Don't Hurry".

  • Impressions From Agile 2007 - Day 1


    Finally, the biggest agile event of the year is under way! We have a big Danish delegation here this year - other than Ative we have met people from  Bankdata, BRFkredit, GoAgile, BestBrains, NDS, Systematics here.

    Martin Jul (left) and Jan Elbæk (right)

    Agile Metrics

    The first day of the conference was a half-day with only a Research-in-progress track in the morning. One session focused on metrics for agile.

    There was a big discussion about the usefulness of metrics. It was clear from peoples experience that good metrics can be useful but using the wrong metrics can be devastating. To this William Krebs of IBM listed 5 Deadly Sins of metrics - metrics that had a lot of overhead to report, the scorecards with traffic lights (people tend to game them to make everything "green"), not fixing the problems that were identified by the metrics, using an inconsistent format so that data could not be compared, and forcing a process on the team.

    Coni Tartaglia and Prasad Ramnath presented a list of metrics that their team at Primavera Systems had decided to use for their project. As part of their Retrospective they had decided on a number of metrics called their "Sprint Build Inspection".

    To measure "Coded to Standards" they used FxCop (for .NET) and FindBugs (for Java). These are static analysis tools that spot common problems in code such as naming conventions, performance and design issues etc.

    To measure the unit tests they used code coverage. It was interesting to see that they defined "good enough" as a coverage of 56% or more. However they mostly used this metric to track how they were progressing towards better coverage as they were developing from a legacy starting point.

    For "functionally tested" they mandated an automated test for each requirement and reported on the number of automated tests. They segmented these into areas - manual (they had gone from many to none), FIT tests, Silk tests and other tests.

    For measuring if the application was "Integrated" they reported on the percentage of unit tests passing, the percentage of FIT tests passing, the percentage of Silk tests, manual and other tests passing. This was used to gauge the quality of the application.

    Additionally, they measured "number of priority 1 defects". The team had made a working agreement and decided that at the end of each sprint no priority one defects were allowed, and during the sprint a maximum of 3 priority one defects were allowed per team and no more than 40 total. Also, no bugs older than 30 days were allowed.

    Finally they used an interesting qualitative approach to overall shippability, namely asking the team to assess whether they would be able to ship the application in 30 days or not. This would be the lithmus test of the overall quality.

    After this we had a big discussion in groups and people also named a number of other useful metrics like not allowing code with higher cyclomatic complexity than 10 (to eliminate the worst design issues), measuring compliance with various internal and external standards (go/no-go) and to measure positive approval from the customer (some would say that would be the ultimate metric!), and also to inspect and adapt the set of metrics on the way, adding and dropping metrics as needed.

    Experience Reports - Implementing Agile in the Enterprise

    The really big case study here was Chris Fry and Steve Greene from Their case: converting a 200+ person development organisation from waterfall to agile in three months. Yes, three months. They didn't like the way their velocity and release frequency had dropped and bet everything on fixing it quickly.

    As Chris Fry noted - there's never a good time to convert to agile, so just pick a bad time and go.

    Here's how they did it: they created created a cross-functional roll-out team with the leads of all the involved silos to oversee the transformation project - development, QA etc.

    Then, everybody got a copy of Ken Schwabers Scrum book and over a two-week period, everybody received a two-hour crash course on agile development.

    Then they converted the organisation into 30 Scrum teams and let go. The company had a 30-day sprint cycle, but teams were allowed to subdivide these sprints into 1 or 2-weeks sprints if they liked.

    Additionally, the sent 30 people from the development organsation for ScrumMaster certification and 35 product owners were also certified to ensure buy-in from the business side. One of they key findings was that they should have started with training the product owners earlier. This is also our experience.

    Some of their key findings

    • The Product Owners should be trained first (ScrumMasters can be trained later)
    • They would like to have used more open-space style events with the individual team members to get more buy-in from the people doing the work faster.
    • They should have introduced outside coaching help earlier.
    • They gave key executives deliverables for the roll-out to assure their buy-in.
    • As they moved to self-organising teams the had very clear rules about the "Done"-ness. This was not up to the individual teams. Instead they set a corporate standard for QA, documentation, test etc.

    The listed a number of keys to success

    • Get executive commitment - this also means that shipping dates are never negitiable. The sprint length and shippability can never be compromised.
    • Focus on the principles - not the mechanis. For example, some teams did not like the Daily Scrum agenda, so they allowed them to make their own agenda as long as they kept meeting daily to communicate about the project and share important information.
    • Also, they focused a lot on automation. Continuous integration with daily build and test was put in place and bugs were treated as stop-the-line issues.
    • Finally they adviced to provide radical transparency - in fact, they sent out a company-wide email with key daily metrics every day to provide a heartbeat for the transition.

    Finally they offered some advice for people embarking on a similar transformation project:

    • Set up a dedicated cross-functional roll-out team to guide the transition
    • Get professional help - outside coaches.
    • Focus on moving the average teams up - get several teams to excellence. Don't waste your time on the high and low performers but focus on getting the bulk to a high level.
    • Provide a heartbeat in the form of a daily metric to everyone.
    • Decide on proper tooling early - for their organisation using Excel for backlog/burndown did not quite scale.
    • Encourage visibility and over-communicate. People need to hear the agile principles again and again to avoid fallbacks.
    • Experiment, be patient and expect mistakes. Just fix them quickly as they arise.
    • And don't take the slow way - go all in, and convert the whole organisation in one shot.
  • Meet us at Agile 2007

    We're off to Agile 2007 next week where I will be hosting a Discovery Session on how to go about implementing agile practises. It is called "Corporate Judo - Guerilla Tactics for Agile Transition". If you are interested in this topic and would like to share your experience to identify patterns for going agile, please join us there. It is on Wednesday at 16:00 in Meeting Room 2.

    Here's the abstract:

    How do we become better change agents? In the agile community we have all "seen the light." We know all the things that are broken in traditional IT organizations. We also know all the solutions. Yet for some reason we are not very efficient at making the transition happen - and even when we manage to change things for the better the organizations often revert to their old ways when we leave. In this workshop, we will work in groups and draw on our experience to identify the best "corporate judo moves": those that make the agile change happen, and make it stick.

    Also, we would like are to meet our blog friends while we are there. If you are interested, please contact me at

  • Planning Poker

    Estimation and planning is an essential part of development, even for agile projects. We have all seen lots of worthless plans, that many in fact that we are tempted to throw planning out altogether. Estimation does not need to be boring, it does not need to be that inaccurate. It can actually be kind of fun...

    In his excellent book Agile Estimating and Planning Mike Cohn discusses the philosophy of agile estimating and planning and shows you how to get the job done.

    In this post I will mention Planning Poker (coined by James Grenning - Planning Poker) as a simple but very effective technique. The rules are few and simple:

    • Each team member gets a deck of estimation cards.
    • The product owner presents one user story at a time.
    • The product owner answers any questions the team might have.
    • Each team member selects a card representing his estimate.
    • When everybody is ready with an estimate, all cards are presented simultaneously.
    • If estimates differ, the high and low estimators defend their estimates.
    • The group briefly debates the arguments (time boxed).
    • A new round of estimation is made.
    • Continue until consensus has been reached.

    I have used Planning poker for sprint planning in scrum teams - but also in release planning when management required long term planning 6-9 months ahead. Using planning poker we had enough accuracy and did not use lots of time trying to detail tasks up front that nobody knew much about - and that perhaps would be replaced by more important stuff before being implemented.

    Ative Planning Poker cards

    So what you need is some planning poker cards to get started doing estimation the agile way. Contact Ative and get a deck of cards.

    A full deck of Ative card is 13 cards spanning from 0 to 100 and 2 special cards:

     "?" = "I have absolutely no idea at all" (to many of these played tells us that the user story most likely is not ready for the current sprint)

    "Coffee" = "I need a short break. I'm too tired to think"

© Ative Consulting ApS