Category: management
One of the core XP practices is having a Customer Team Member. It means that development teams have access to the newest information from the customer's side and they know about all changes in the requirements very quickly. Having on-site customer (or customer proxy for commercial products with lots of potential customers) ensures that requests change informally, the process becomes flexible, and saves the cost of formal overhead.
In this post I would like to take another look at this practice. I would like to share with you my thoughts why having a Customer Team Member can help the development team win together with their customer. And I would like to take a "social" view on this practice.
Bookmark/Search this post with:
No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?
This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.
In this post I will try to explain "Defer Commitment" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.
As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).
Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.
In this post I will try to explain "Optimize the Whole" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
In the previous parts of this series (1, 2, 3, 4), I went into a lot of the initial issues of how we ran our project and some of the things we did wrong. For Part 5, I'm going to focus on the 5 big mistakes we made in the project before I move onto another phase of the series.
For some background, the project was to integrate an off-the-shelf (but highly customizable) billing system to replace an aging custom Oracle forms app. This was our company's first foray into Scrum and Agile as well as the first Agile experience for most of the development team. After we sailed past our second management-imposed deadline I started thinking about how we could correct our process for this project and the next ones we do, which led me to write it all down in this series. Keep reading for the Top 5 mistakes we made (in no particular order). Where possible I also give some detail about how we've worked on correcting our process. I hope this list helps you avoid these mistakes and make your own all-new ones. :)
Bookmark/Search this post with:
Welcome to Part 4 of My First Agile Project. If you haven't read the others in the series, don't worry. Each part should stand alone. If you want to read the whole story though, the other parts are available: Part 1, Part 2, Part 3.
In Part 3 of this series, I talked about our demos and I mentioned how they unfortunately turned people off the demo with presentations about mostly behind-the-scenes features. My first instinct was just to say that those people lost their right to have input since they weren't involved in the demo. In reality, the business world just doesn't work like this, much to my chagrin.
What happened was the people who didn't care to come to the demos just came later with changes and "suggestions" for new work we had to do. Also, since a lot of the ones who were supposed to be coming were upper management, their lack of knowledge about the Agile processes we were using led to a lot of problems and misunderstandings later in the project. Read on to hear more about how we failed to get our management on board as much as we should have. Hopefully you can avoid that mistake and some of the problems we've faced.
Bookmark/Search this post with:
Work in small batches
I've always thought that delivering small pieces of software is easier than delivering the BIG BANG product at once. Small software package is easier to manage than the big one, you can expect smaller amount of defects there, it is much easier to integrate it with existing software. Isn't that obvious?
On the other hand working on the new version for, let's say, six months without regular integration in the production environment (if integrated at all) will bring you much more problems. Defects will accumulate and just before the release someone will discover them. No surprisingly developers would have to work overtime to fix them.
Bookmark/Search this post with:
Software organizations have surprisingly more problems managing people than managing soulless machines. People are also surprised when they ask me what my job is all about and I tell them that I work with people most of the time. "But you are a software engineer - isn't your job about working with computers?". "You're partially right because I work in a team and program a computer using programming language to do what you want to do is much easier than >>program<< my colleagues to work with me to reach our team's goals" - I tell them.
Working in a team means not only solving technical problems, designing stuff and make decisions together. One of the most important factor that makes teams successful is Respect.
In this post I will try to explain "Respect People" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Title of this post is a paraphrase of great quotation, namely "Don't bring me problems, bring me solutions" which is or rather should be sometimes used by project leaders and product owners (also referred as managers later in this post). However bringing problems to Scrum Master is a very good idea - some problems are out of your control, especially those managerial ones (but this is a subject for separate post).
We, engineers, are taught to solve problems and we do it right. We are creative and intelligent people, hungry for non-trivial puzzles to solve. We should receive problem as an input and give solution as an output - that's it (of course we need a lot of communication in between, clarifications, details, etc.).
Why managers/leaders/product owners sometimes treat developers as machines to write the code? Why they don't trust developers and don't believe they really have knowledge and skills to solve many business and technical problems and turn them into working software? Why don't they accept the fact that when development team encounters any problem they will try to solve it and if they fail they will let them know.
Of course, it's not fair to say that every manager and leader has such mental problems I described above (I was lucky for most of my professional life) but let's focus on guys that really think they know everything and thus kill team's creativity.
Bookmark/Search this post with:
I just finished reading a little book called Fish!. It's subtitle is "A Remarkable Way to Boost Morale and Improve Results". I'm always interested in management literature, and with a size of only 107 small pages, this booklet was simply too hard to ignore. There are quite a number of publications on the Top 100 list of Software Engineering Books that (more-or-less) deal with the same subject: how to improve job satisfaction (among software developers and other team members), and how to improve the quality of software delivered to customers.
Bookmark/Search this post with:
RSS feed