epistemologic

Amit Rathore’s blog about software project management

Archive for March, 2007

Lean Software Development and the Theory of Constraints

Posted by Amit Rathore on March 25, 2007

I’ve been trying to apply lean software development principles on my project for a little over a year now. So, when I recently re-read Mary Poppendieck’s Lean Software Development – An Agile Toolkit, I thoroughly enjoyed it and found I was nodding to myself a lot. I highly recommend reading this book because it explains in very simple terms what this whole lean process thing is about, and how it relates to software development. A knowledge of why Agile processes work and what they’re aimed at would help, but is not essential.

For those who don’t have the patience (or time) to read the full book – here’s my version of a summary -

- Strive to eliminate waste. Waste comes in many forms in the world of software development, all of these is waste – partially done work, extra processes that add no value, extra features that have little impact on business value, task switching because of multiple objectives or other reasons, waiting for something, having to go somewhere (to meet someone or fetch something) to get information, defects, and ‘management’ activities.

- Use a technique called value-stream mapping to understand where the process you’re using delivers value and (more importantly) to determine where it adds none.

- Amplify learning through feedback. This is easily done through short iterations and negotiating scope for each of them.

- Think about set-based development techniques.

- Delay commitment – decide as late as possible. At the same time, think about concurrent development.

- Deliver as fast as possible – this enhances learning, and delivers value at the same time. Use concepts from pull-systems and queuing theory.

- Understand the cost of delay – use a product model. Have an accountant on your team who can help with this, and make trade-off decisions in light of what the model says.

- Empower the team!

- Think about integrity – both conceptual integrity, and perceived integrity.

- Testing – TDD, automated functional testing, continuous integration – is key. Refactoring is key.

- Always optimize at a level higher than the perceived issue. Employ systems thinking.

- Embrace the idea of Customer Collaboration vs. Contract Negotiation.

I’ve found that as I started to apply lean software development methods, our processes started to become more and more natural, and that the team became more and more effective. As expected, the team members themselves began to look for new and innovative ways to optimize their workflow, and my job as a project manager became easier and easier from that perspective.

Speaking of optimization, I recall being introduced to the writings of Eli Goldratt by a really smart project manager I worked with in the past – Matt Gelbwaks. Goldratt writes about the Theory of Constraints – his books The Goal and Critical Chain are a really good start to the whole discipline. He has a really simple algorithm to optimize a system, based on throughput accounting –

1. IDENTIFY the system’s constraint(s)
2. Describe how to EXPLOIT the system’s constraint(s)
3. SUBORDINATE everything else to the above decision
4. ELEVATE the system’s constraint(s)
5. If in the above process, a constraint has been broken, GO BACK to step 1 but do not allow inertia to cause a system’s constraint.

Applying the Theory of Constraints to improve my teams’ processes, while using lean software development ideas to drive agile practices has proved absolutely invaluable to me over the past year.

I’d be happy to hear from you if you tried similar things on your project… and about how they worked out…

Posted in agile, books, lean software, process, project management, reviews, theory of constraints | 2 Comments »

Using mind maps to start planning a project

Posted by Amit Rathore on March 11, 2007

As you might have read earlier, I recently started a new team that has been chartered with building a suite of new products from scratch. The business folks have been working in the domain for a long time and have built similar products before. Despite that, requirements for the new products have not all been nailed down yet, making this project somewhat of an ideal situation to start a new team. We’re using Agile (Scrum with XP practices) methods, and I’m infusing several ideas from Lean Software Development into the mix.

I used a new tool to kick-ff the high-level planning sessions this time. I’ve been using mind maps (FreeMind, Mindjet Manager, and NovaMind) for a while now: for various things – keeping track of to-dos, planning my personal projects, thinking about high-level goals, brainstorming and brain-dumping, and so on and so forth. I’ve always felt that such an intuitive tool might make for a great way to facilitate work sessions, especially when the work at hand is fairly high-level. An example might be – early stages of planning.

In my opinion, using the tool turned out to be quite a good idea. The first meeting lasted three hours (including coffee and a 10 minute break), and had about 12 participants with me facilitating using a whiteboard and sticky flip-charts. I ended up with several mind-maps including one for the overall project layout, one for training requirements, and another that detailed a particular module. The whole team was able to participate in building it as it was merely a form of a brainstorming exercise, with some extra structure.

Here’s a mock-up of one of these mind maps that got produced at this session -

projectX.png

One possible next step is to pick up the area which needs to be worked on first (actually this will probably be more than one – for example, the architecture-spike and config-management piece will need to be done in the beginning regardless of what else gets picked up) and continue to drill-down into its details. When sufficient granularity has been achieved, the leaf nodes of the mind map can be translated into backlog items (or phrase-level user-stories). Of course, this will mean that the brainstorming will need to be done with an eye towards this end goal – and all the guidelines around writing good user-story phrases will need to be kept in mind.

Overall, it was a good exercise – it was interactive and fun. More importantly, it was a visual way of representing the project and its potential scope – and was a great start at arriving at a shared mental-model of the system. Having all members of the team present (developers, QA, BA, and sponsors) helped a lot as well.

Note: I didn’t use the actual software in the meeting, instead, I chose to draw on the whiteboard and one of the participants (the sponsor!) volunteered to scribe. This let the session be more about the content than about formating and word-smithing. I later converted the notes to soft-copies using FreeMind.

Posted in agile, meetings, mind maps, process, tools | 3 Comments »

Pay incentives vs. motivation

Posted by Amit Rathore on March 10, 2007

I’m sure you’ve had many conversations with people about what motivates people, and how to get them to work smarter or harder or to get them to do the right thing. Compensation – money, stock options, bonuses, and other similar perks quite often figure in these discussions. Yet, there is usually a thread about how these don’t really seem to work that well, or perhaps not at all.

Here’s expert commentary from someone who has spent many years studying management practices – including what kinds of incentives work – such that people are intrinsically motivated to do the right thing towards the end goal. This testimony was given to congress, no less.

[Originally from Esther Derby]

Posted in organizational, project management | Leave a Comment »

Agile: Starting a new project

Posted by Amit Rathore on March 6, 2007

This one is intentionally going to be somewhat vague. I’m starting a new team this week (we’re using Scrum, and I’m going to be the scrum-master), and I was talking about this with various project-manager/scrummies on the multi-team project that I’m presently on. We were discussing lessons learnt, ideas, tips/suggestions etc. about sprint zero.

I’ve been on Agile projects for several years, Scrum for a couple of years now – both as a developer and as a project manager. I’ve been playing a scrum-master role for the last year – on a large team that I picked up six months after it had been started. Now, it’s time for a new team.

Sprint zero would include setting up the backlog, getting product owners aligned, getting developers who’ve not necessarily used a lot of real Agile practices before educated about things, figuring things out around the architecture, deciding what to track and how, deciding on length of iterations, and so on and so forth. Basically everything that might come to mind when starting a new project.

I’ve got several ideas put together for what might be a good way to go about this – but what are the top few things that come to your mind when you start a team?

Posted in agile, process, project management | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.