Does Lean Software Developement Motivate?
Here is an excerpt from an interesting blog I read on Lean Software development.
Empower the team
There has been a traditional belief in most businesses about the decision-making in the organisation – the managers tell the workers how to do their own job. In a Work-Out technique, the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. Most experienced project managers have simply stated the key for a successful project – “Find good people and let them do their own job.”
Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organisational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to Customer; the team leader should provide support and help in difficult situations, as well as make sure that skepticism does not ruin the team’s spirit.
Empower the team
There has been a traditional belief in most businesses about the decision-making in the organisation – the managers tell the workers how to do their own job. In a Work-Out technique, the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. Most experienced project managers have simply stated the key for a successful project – “Find good people and let them do their own job.”
Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organisational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to Customer; the team leader should provide support and help in difficult situations, as well as make sure that skepticism does not ruin the team’s spirit.
Replies to This Discussion
-
Permalink Reply by Susan R Grossman on -
I agree with the first one on the importance of good management who really listens to the logic a developer is trying to express.
I worry about establishing any direct relations between the client and the developer. It shouldn't be necessary if there's a good, skilled project manager or analyst working with the client and the development team. But then, I'm coming from the developer side of it.
Occasionally it's OK bringing in the developer for presentational explanations, or to ask questions that only they can explain what's being asked; in a controlled meeting environment, run by others. The buffer for the developer is too important to jeopardize since it effects productivity when it starts to break down and risk rises rapidly.
Yes, it could motivate the developer to really understand what the client wants and want to get it right for them, to milk all the little details of the requirement out... and to deal with the client over and over trying to get every possible scenario as time ticks and everyone gets frustrated because the developer doesn't have the skills to really talk to and understand the client, or make themselves understood.
Also once communication is opened often the client then starts communicating directly with the developer, which frustrates everyone more. Not many PM's like it when the client phones the developers desk.
I don't mind being a resource, am proud of how I can juggle projects in my assigned percentages and would prefer team motivation as my higher purpose as compared to having communications with the client.
-
Permalink Reply by Vanya Tucherov on -
From a PM perspective, I'd concur with most of what you say.
I don't want stakeholders/software consumers or their proxies getting in the habit of interacting directly with development. When that happens, the whole process starts the descent on the slippery slope into scope creep and project chaos- because what the requestor is taking to the developer becomes unplanned and unknown work. If the work does get successfully completed, it establishes the wrong precedent- namely that it's ok to take things directly to the developer and bypass process, which then tends to breed even more of the cycle of short-cutting the whole process.
With that being said, I want stakeholders in our scheduled planning meetings, because they can clarify any questions which may be broached about facets of the work which is being done which hadn't been satisfactorily clarified in analysis. Similarly, I want my development team to have a seat at the table when we're demonstrating completed iterations so that they can answer questions about how things were implemented.
Where teams seem to fail in implementing lean SDLC methodologies seems to be from taking too many shortcuts and minimizing too much, and tranforming methodologies like Agile into FRAgile, with the initial F and R standing for Failure Ready.
-
Permalink Reply by Jonathan Starr on -
Speaking as a developer, when a PM gets in the way when I am trying to gather requirements, it's an epic fail.
The most natural way for a manager to work with developers is as a facilitator. If you do your tyrant thing, we developers will turn our attention to more interesting projects.
I've dealt with PMs like you, and it's crappy to have to jump through unnatural hoops to get decent requirements and feedback for projects.
What's nice about Agile is that I always get the specifics for requirements when I need them, and get feedback continuously from my customers.
Obviously you don't understand Agile, because it does formalize a process of interaction between customers and developers.
-
Permalink Reply by Jonathan Starr on
-
You're doing Agile wrong then.
-
Permalink Reply by Alan Levin on -
This is a great philosophy. So many times, managers both IT and Project do not invite discussion--its their way or the higway.
-
Permalink Reply by Nancy Babyak on -
I have found that to be 'lean' is to be careful on access... if the organization has been an open door with no SDLC, no change management, no structure... you are better off breaking the ties that bind bad habits and sheltering your devs from business bullies and putting the controls in place so that status / issues / input flows in an organized manner and gradually step back into a 'leaner' model.
'Let them do their own job' also means that there is a level of trust across the organization so that people feel open to discussing set backs and resets without fear of cutbacks and poor evaluations.
I'm all for getting the right people in the room to have powerful creation moments... but not if the agendas are skwed and my team becomes the target I would prefer to keep a measured distance.
-
Permalink Reply by Jim Gettman on -
Managers make decision and tell workers how to do their job. Wow. It sounds normal, but it is not common. One of the things that demotivates me is a manager unable to make decisions or describe how they want things done. Thankfully, I am now blessed with a leader that can do both. I disagree with many decisions and directions, yet I am motivated and productive because my boss doesn't dither and consult, and has the technical chops to understand and lead our project.
As a IT worker for a service business, most of the technologies I use and implement are ugly - bloated, slow and tied to a mess of tech bought before my arrival; that is fine. What I can't take is a manager that doesn't know what they want, won't listen to their team, but will listen to other managers. There is hardly a more certain way to get bad, demoralizing decisions than a committee of managers.
-
Permalink Reply by Greg Bohrn on -
I've found that there has to be synergies in both directions. I've worked with groups that “Find good people and let them do their own job” and the projects have failed miserably do to a lack of focus and direction by business management. I've worked with groups in the opposite direction where everything is fed down from management and have seen these fail as well due to lack of technical understanding of what the business problem is. There needs to be a balance between those of develop the product and those who manage the product development. I've fallen into the concept of managing with a vision. As most of development processes out there from Waterfall to Extreme Programming have fundamental flaws. None of them truly capture the here and now. As a good manager of people, you need to understand you people, their strengths, their weaknesses and what motivates them. Some engineers want a long leash to come up with stellar solutions with little guidance. Some engineers want a lot more guidance on the the project is and what their part in the project will be. None of these capture the essence of the human condition. (By the way, I'm a process junkie as I'm always looking for a better way to optimize what I do and what my team can accomplish). Personally, these days, I use a modified SCRUM process for processing and monitoring work products. I do a lot of up front requirements and design (which does not follow SCRUM). I also do not have the team meet every day as I have had this described and "self-imposed micro-management". We meet twice weekly, focus on the work products and keep major requirement changes shelved unless business necessitates a change. I've used various other processes in the past, most successfully. A lot of what I use I got from my Master's degree program, various process and project management disciplines and a lot of useful information from the www.construx.com website.
I like to tailor my approach to management based on the team to include upper management as well as the development team. It takes a good manager to have a successful project, not a process. I do like the Lean processes for myself though. I've been doing this for quite a long time and get frustrated with management structures that do not take feedback up from the development teams (who are the experts in product development). All parts of the business play a role in defining and developing product and all stakeholders should take note of this (developers and managers alike) .
-
Permalink Reply by Mona Everett on -
Your link to 'Lean Software Development is Broken (404 error). I actually would have liked to read the page because this is a new term for me.
-
Permalink Reply by Mona Everett on
-
I agree with everything in this excerpt.
The best managers are generally the ones who tell you what the problem is, ask you what you need to get it done, and then make it their business to make sure that you have what you need.
I was rather surprised by some of the comments where developers did not want to talk to the client. If you do NOT talk to the client, you will never be sure of what the client is actually looking for. I am rather a fan of Rapid Prototyping, which keeps the client involved. An involved client shares ownership of the project and is usually a happy client.
The 'find good people and let them do their job' metaphor is great; unfortunately it may well be 'find good people and do it my way'. In that case, a great deal of creativity and new knowledge is missed in the process.
-
Permalink Reply by M. Edward (Ed) Borasky on
-
There are so many different styles of software project management, ranging from strict and highly structured SEI CMM to Agile, Scrum, Extreme Programming, etc. I can't speak for all developers, of course, but I don't think even the strictest of processes is de-motivating, nor do I think even the loosest of processes is highly motivating.
For me, the motivating factors are, in order:
1. Money. I know that many surveys are going to tell you something different about money as a motivator, but I got into programming because I am good at it, I enjoy it, and I can earn a sustainable living at it. Take away any one of those and I'd be doing something else.
2. Usefulness of the software as measured by the end user. It's easy for me to tolerate highly-structured processes if I know the end product is going to be a good one. And if it isn't going to be good, no amount of "fun" can make up for that.
3. Technical challenge. I've solved some pretty difficult problems, and I hope to solve many more before they pry my cold dead fingers off of the keyboard.
-
Permalink Reply by Kevin Jenkins on -
This a great post Ed. There are many motivating factors for IT professionals but I really think this gets to the essence of it ... especially 2 and 3 ... it seems to me that many of the other motivational factors could be considered derivatives of these two core factors.
Cheers,
Kevin
P.S. Please carry all future discussions over to the new site at http://www.tech-pro-motivation.com. Thanks!
About
© 2010 Created by Kevin Jenkins.
Powered by 
.
