|
|
|
12/06/2011 03:59 PM
|
|
|
Hi,
I do believe that the Lean community accepts software development also as a candidate for applying Lean practices.
Lean places a lot of emphasis on 'go see' at the Gemba. That is fine in an assembly line, but how does one 'go see' in a software development unit where the 'product' is invisible ? I have put down a few ways one can 'see' what is happening. However, i suspect the developers would complain that their manager is breathing down their neck or that this has a Heisenberg effect of slowing down their pace . Any comments ?
1) Check out the work of the developers and do an informal review of it
2) Run tests on the software checked in
3) Sit down with the developers as a passive 'pair programmer'
4) Talk to each of them at some time and discuss what they are doing and how they are going about it
5) Get your hands dirty and participate in the development
6) Have a daily 'scrum' meeting and find out what they did the previous day, what they plan today and their problems
7) Act as the virtual customer and do a pseudo test run in a simulated production environment
8) Write documentation and release notes to get a hang of what is going on
9) Prepare test cases
10) Run performance tests or walk through the code by stepping through the statements in a debugger.
Do these sound like good ways of 'go see' in a software environment ? I am asking since i have wanted to but never got down to doing any of the above.
Thanks and regards
Edited: 12/07/2011 at 11:38 AM by Lean Moderator
|
|
|
|
|
12/07/2011 11:29 AM
|
|
|
Hi Moko,
In Lean Software Development, it is common practice to make the flow of work visible using a kanban board (several books exist on this topic). In this way, it's possible to see where work is getting blocked and/or building up (WIP). A daily review of blocked items should keep things moving along.
Frequent occurrences of the same problem can be addressed through traditional Lean root-cause analysis. Incremental improvements (suggested by the team) to process and procedures can be then be made and the effect of those changes can be measured in terms of lead time, defects, due-date performance, etc.
In order to catch and measure code defects early on you could put into place the practices of automated unit tests and continuous integration (with built-in checks).
And finally, there's nothing like delivering functionality frequently (in small batches) and getting it in front of the client and/or customer for feedback.
I know that's a pretty high-level answer to your question, but I hope it helps point you in the right direction.
Regards.
>Jeff
|
|
|
|
|
12/15/2011 03:26 PM
|
|
|
I think this is a good discussion, and there are definitely many ways that Lean Software Development techniques can help make the work visible and interactive so it flows smoothly and with less waste. And having all stakeholders participate with the development team in regular standups and reflections, surrounding by visuals that reflect the targets, status, and problems is very helpful.
But let's not fall into the trap of thinking that the software development process is all there is to this value stream.
Who is the customer? What is the problem we're trying to solve with this development project? And what is the value they wish to realize?
Is more software really needed, or is it possible, if we go to Gemba (the end customer) and examine very carefully, perhaps we discover that we should simplify and improve the business process, and thus reduce the amount of software that's needed to support it? Remember a key mantra of the Agile development community is to "write less code"
Or if the software under development is to be embedded in a product or service that is delivered to the customer, how do we know what the design should be? What does the customer really need, and how does that compare to the "requirements" that we're designing the software to meet?
The important issue is this - every value stream must understand what the ultimate customer needs and values. And the ultimate customer for a software development project is the individual who will use the new system to add value to whatever they're doing. That's the Gemba that everyone along the value stream (including the designers, developers, testers, IT operations and service people) must "go see" to ensure value is delivered
Once they know what the customer needs, then they can go about designing, testing and delivering it quickly with the least waste, this is where various visual approaches, kanban, etc. are useful
Steve
|
|
|
|
>
Community >
Forums
Send to a Friend
