Introduction to Agile project management _A very simple example
Before I jump into the the article, I’d like to share the key take aways that you can expect:
_ If you act agile, you can leverage way faster of what you have created. Already during the creation. This will help getting your stakeholders engaged.
_ Validating between every sprint brings you closer to the actual demand and it reduces risk to build something, that is off the actual demand. Especially within a dynamic environment.
_ You might get to plan more thoroughly by traditional models and be more efficient, but you’re never completely safe to run into surprises that might screw your plan.
_ Working agile reduces the risk tremendously of putting effort into something that turns out to be unimportant.
Still interested. Great. I’d like to use a very simple example to get you familiar with the approach of agile project management vs. a traditional way of executing a project. The Project is a bicycle. When I moved to Portland, I figured how much of a biketown this city is. So I wanted to get an old bike going again, because this one got even more style than all the fixes around the city. And as I am a busy man, I can only do this a couple of hours on weekends. So I needed to come up with a plan. Please don’t get me wrong, I’m not making an official project out of ALL the stuff I want or need to do. But if I would, I would have had these two options.
Waterfall. As drafted in the pic, I could have planned the whole thing through. Making an analysis, buying all spare parts and than executing step by step (Wheel, powertrain, breaks, lights etc.) until I would have finally been at the stage of re-assembling after multiple weeks and going for a test ride.
Imagine the following two scenarios are coming up:
Now we are jumping to agile and how I would have handled those circumstances
_ first: I would have figured, that the powertrain is more complex than I thought in the beginning. I would have needed external support. A workshop or some expert. My whole costing and timing would have been screwed. No deliverable on the final deadline until that gets solved.
_ second: Riding the bike at the test drive wouldn’t have been as pleasuring as I expected it to be. Maybe I just overestimated my skills or the conditions of my bike. Disappointment would have been big and the whole project was questionable in the end and maybe a big waste of time.
Agile (in this case Kanban). Starting with the Kanban Board showing my task backlog in order of prios. I’m setting my “work in progress” limit to one. Meaning, I’m only having one task at a time in the “In Progress” column. This is essential to keep priorities straight and strict.
As tires are flat. This is my prio number one. Powertrain comes as prio two, because Portland can be quite some up and downhill. And so on and so forth.
Because I don’t need to order all parts at the same time like I would try with waterfall, I visit my local bike shop on Alberta Street, get the tubes & tires and fix them right away. Time is short, so I can’t fix the powertrain (my next priority) on the same day, but I still have enough time to clean the bike and order all other parts that I’m going to need for sure within the next weeks and put “Wheels” into the validation column. Validation basically means, I’m using my bike to go around the neighborhood, test the new functionality and already leverage a functional, but not close to perfect, bike.
Next week. Powertrain is next on my prio list. As it is more complex. I’m am using the Breakdown column and divide it down into “chain” & “bottom brackets”. Figuring that I can change the chain pretty easy, the bottom brackets turn out to exceed my capabilities. I re-assemble the bike at the end of the day and put “bottom brackets” back to the backlog. During my next validation period, I’m going to check whether it is really necessary to further invest or if I can live with that minimum standard.
Week Three. After the most recent validation, I decide to prioritize breaks and lights over the perfection of the powertrain for now. I’m working on getting those items done on two weekends and enjoy validating all functions in between.
After 4 weeks, I already have a full functioning bike, that is clean with working light bulbs and proper breaks. Meanwhile, I figured that I’m using this bike only for my neighborhood which hasn’t any uphills. Longer distances, I will do with my road bike. So the expensive repair on the bottom brackets disappear from my list.
Looking back at the two issues I described above. Bottom brakes  and the unsatisfying test result . First issue from above is already solved as I validated and reprioritized the request during the ongoing project. Not unusual in a dynamic environment. If that wouldn’t have been the case, I could still have given my bike to an expert to fix the issue, right? But about the second issue. Through all the validations in between, I got a way better feeling on what really is needed to be fixed. Maybe I also found additional items that came up during my validations that I didn’t think of before. So I have full control about what I’m prioritizing and what is the minimum requirement to make it a successful project. I can adjust the target, the purpose and the aspired end result during the ongoing project phase. Worst comes to worst: If I don’t like riding the bike in the end, I can still give it to charity but had great weeks riding it with style to work and around my neighborhood.
Obviously, this is a very simple example. I guess most of your business projects are a lot more complex than this. One thing is also important to me. I don’t think that agile is working in every company. But if you find your company in a dynamic or even disruptive market, having an agile culture will help to sustain within that environment.
If you are interested in agile project management. Visit my profile. There are further articles around this topic. Done.
Originally published at https://www.linkedin.com on October 19, 2017.