I came across Twitter in a discussion on LinkedIn a few months ago and recently wrote a blog entry on how it might support agile software development practices. However, I've only recently had a chance to explore its actual effect on a project.
Continue reading "Using Twitter in an Agile Project Setting" »
One of the biggest challenges of Agile development is introducing its ideas and techniques beyond the project team using them. Project teams tpically see direct, and often immediate, benefits of using agile techniques but for those outside of the project it takes the right leadership and direction to enable agile adoption across the enterprise.
I recently updated a template on my website that I frequently use when either leading iterative development projects or coaching project managers on effective iterative development techniques called the Iteration RouteMap. The word 'routemap' comes from a South African colleague who used the 'king's english' and insisted that the term routemap was more appropriate than roadmap, the name's stuck ever since!
As far as templates go this one is really quite lightweight, however, there are several key concepts that are important when managing projects in general and iterative projects in particular. The first is using a mechanism to determine how to size effort. I typically look at this from the perspective of size and complexity (which is usually a good indication of risk). Large and complex work items should be started early in the project lifecycle. I also estimate using Perfect Engineering Days (PEDs), this illustrates how long something should take without interuptions, well defined requirements and all of the other components that can impact how long it actually takes. A Load Factor is then used to convert PEDs into a realistic estimate. The Load Factor reflects the productivity of the project and is typically between '2' and '5'. A '5' reflects a programming language that is either new to the development team or difficult to work with (such as Visual Basic 4/5 within an object oriented development environment). 2 is usually only achieved when the development team has been working on a project for an extended period of time, usually near the latter iterations of the project (when development complexity should be lower). It should be noted that as you actually get some iterations completed you can start substituting the Velocity of your development for the Load Factor.
The final item is to recognize that there are different Types of functionality/value that will be completed during an iteration. The logical work items are user stories that represent tangible units of business value that stakeholders can identify and provide feedback on. However, often these stories need to be supported by 'Infrastructure' stories which ensure a well designed system which can support its non-functional requirements. In addition, the User Interface (UI) necessary for the story can also be decoupled from the story iteself and is often represented as a separate work item.
Hopefully this template will be useful to both those just starting their agile/iterative development initiatives as well as those who have been doing this type of rowkr for awhile. As usual, please feel free to email me with comments.
As a project manager for many years I've developed a long litany of techniques and approaches that have helped me manage a wide range of green-field software development, COTS (Custom Off-the-Shelf), and Hardware implementations. Most of my website is focused on successfully enabling technology to support business value and managing how this happens is covered throughout. However, here are some brief perspectives that guide a lot of how I view and manage projects.
Project management begins with the emphasis on liveness; that is conferred by agile methods, especially SCRUM and XP. These techniques emphasize collaboration and 'just enough' structure to meet end-user requirements. However, these techniques were not intended to replace or ignore the many other aspects that affect projects such as budgeting, resourcing, communication and the remaining elements of the Project Management Institute's Project Management Book of Knowledge.
I can imagine that many agilists reading this might be recoiling at the thought of the high ceremony, document-centric and waterfall nature that many armed with a PMP certification possess. From my experience this is more of a reflection of the personalities of the people who have earned these certifications (and granted these personalities tend to gravitate to this area). One reason I suspect is that as a project manager there is an underlying desire to 'control' the project and its easy to use the PMBOK (and RUP for that matter) to justify this approach. However, I also firmly believe that effective project managers understand the Agile Manifesto Principle of 'Individals and Interactions over Processes and Tools', these PM's enable their teams so they can control the processes (not abandon them) and that they respect and support their team members to increase their effectiveness.
The biggest change that I experienced in managing projects came when I managed my first iterative development project. The term Iterative Development has many characteristics (some of which you can find in an article I wrote called Hallmarks of Iterative Development) but chief amongst them is their consistent and 'time-boxed' duration (you can learn more about selecting the right iteration length here), rapid feedback, demonstration of business value at the completion of each iteration, and an emphasis on high risk and architecturally significant work first. I've run iterative projects using small teams, large teams, geographically dispersed teams and with a wide range of techniques (Walls of Wonder, Kanbans, and Commercial software). All of these shapes and sizes have different benefits and challenges but what I can say is that without using the Iterative development techniques mentioned none of these projects would have been successful.
One of the early challenges faced by most project managers and sponsors involved in an agile/iterative project is determining how long each iteration should be. Surprisingly there isn't a lot of guidance that can be used to determine an appropriate iteration length (although Mike Cohn has some good thoughts on the topic) with the result that most iteration cycles are determined without much context on the problem that is being solved.
Here are some quick guidelines I would offer and they're based on some underlying assumptions about an iteration and its characteristics:
Iteration Characteristics
Iteration Length Considerations
Iteration Length Selection Process
Signs that your iteration length is incorrect:
Changing your iteration length mid-stream through a project isn't something I would generally recommend (you should only do this after you have at least 3 iterations completed and have some of the signals mentioned above), consistent iterations provide a cadence and rhythm to your project and tampering with that will distort your measurement statistics and also disrupt the team. However, if you give some thought to the purpose of your iteration you should be able to avoid this problem.
I came across some interesting material from Rally Software Development recently which closely aligns with what I consider the most important elements of effective software development techniques. One of the things I particularly liked about the whitepaper Rally has published (Tactical Management of Agile Development: Achieving Competitive Advantage) is that it provides more visibility into the somewhat nebulous concepts of "Release Planning".
In their paper, Leffingwell and Muirhead, describe Release Planning as the exercise which occurs at the start of a project where product owners, the development and customers (or their proxies) agree on the set of scoping and scheduling activities around which each iteration should occur. They identify a lightweight process where they have abstracted several high level workflows, specifically "Define Release Objectives", "Scope Release" and "Schedule Release". This creates a Release Roadmap which they emphasize is a coarse grained release plan which is neither comprehensive nor guaranteed. This exercise could be a 2-3 week effort based on the size of the project which sits well with how I would advise an organization embracing a larger program initiative.
They also distinguish between "Schedule Driven" or "Scope Driven" projects. The former is defined as having a specific date which is required for implementation and based on this scope is adjusted based on the team's commitment to deliver and velocity observed over progressive iterations. Scope Driven identifies a list of prioritized backlog items from which a schedule is derived. The thing I like specifically about focusing on two general approaches is that there is considerable value in picking a specific metaphor at the start of the program and moving forward with that goal in mind.
Too often I have seen organizations attempt both approaches although typically this is difficult to see initially. It typically occurs when there are two or three groups with equal decision making capacity in the program. You know this is happening when you hear a group of key stakeholders agree that they want to apply a schedule driven approach but you hear one of the stakeholders add something to the effect of "After we define a solid architecture" or "Once we have a good handle on the business requirements". These statements are so nebulous and open to such wide interpretation they essentially prevent a Schedule driven approach from being applied. The architects will head off and debate Hibernate versus OJB for several weeks, the business representatives will disappear and hold lengthy all day meetings trying to agree on what business processes are currently being performed. Both of these activities might have value but they shouldn't cloak the fact that the project should be more scope driven (which by the way might include architecture validating activities not just business value activities).