Encouraging lean practices in a agile/scrum team

Question

We were practicing agile scrum for several years. So far so good :).
What we feel is now that the team is more focused on completing individual tasks instead of thinking about the whole purpose of the project. This leads us to have some rotten code and some performance issues.
As a solution for this I would like to encourage team to practice lean principals.

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

The principals like Decide as late as possible will improve the code quality , performance and at the end I need to achieve See the whole.

My questions is what are the tools, matrices can be used to encourage the team on these principals. Specially how can I achieve 3 and 7 ? (I think I can say others are already there up to some extent )

Answer 1

If you're getting rotten code, then the team's not really completing the stories, are they? I assume your definition of Done includes having sufficient unit tests and acceptance tests, having them pass, and having well-structured (i.e. refactored) code; if it doesn't, I recommend you change it so it does.

I'm guessing that if the focus is on doing individual tasks, then:

1) The individual tasks are visible to the team, and the overall value delivered by the sprint isn't, and

2) The team members are individually rewarded or rated according to number of tasks reported done, and not by the overall value delivered by the sprint.

If you want the team to be delivering value overall, you need to measure (and make visible) value at the team level, not effort at the individual level. (This is an example of See the whole, by the way.)

Performance is also a matter of the whole system, in a different way: the only parts of the system that you want to spend effort speeding up are the bottlenecks. Being a bottleneck is not a property of a part of the system (even the part that's currently a bottleneck), but of the whole.

I recommend you measure the performance of the system frequently, either every day or on every integration, whichever is more frequent. This will let you know when performance sinks below a threshold, and give you an idea which changes partially triggered it. Improving the performance should probably take the form of stories: usually a spike to try a particular optimization approach, then (if that's successful) a development story to implement it.

Constant refactoring will help you achieve 3 (Decide as late as possible). Regular retrospectives will help your team achieve 7 (See the whole). They are also an opportunity to 1 (Eliminate waste), especially if you include an activity in your retrospective focused on identifying waste (hint: look for work piling up in queues).

I hope this is helpful.

Answer 2

I would encourage you reading this blog post as it offers a variety of practices that are meant to promote planning on demand, team involvement and rapid delivery. Also, in my opinion, you might perform all three types of meetings for team collaboration: planning meeting, daily meeting, retrospective meeting. Such approach will allow you to communicate and interact with your team, thus, keeping them occupied and aware of current situation in your project.

Answer 3

What we feel is now that the team is more focused on completing individual tasks instead of thinking 

I used to have experience such as yours where programmer are competing against each others to score more during the sprint review when we show the burn down chart. The format of my burn down chart is per individual. What i try to do to increase team work is eliminate the burn down chart that only show how many points a programmer burned.

To further improve that , i only put how many points burn per project. Let's say Project A, i have 5 programmers working on it, then by end of the day ( Sprint Review ) i will show what we've done

Answer 4

To make developers "see the whole", the PO needs to discuss the vision with them. He needs to define, at least, the next big-picture goal of the project and explain it to the developers. For example, he could do milestone planning. Milestones typically consist of multiple stories/epics. Discuss the next milestone when the last is reached, gives developers the big picture.

Unfortunately, in my experience this can endanger "decide as late as possible". Developers that know "the whole" tend to try to anticipate things. The simple-design principle is one of the most difficult things to learn. This is an experience and mind-set problem. Even though I'm perfectly aware of this, I do it wrong oft as not. The problem is that intuitively it's the wrong thing to do. In fact, anticipating things is not wrong. It's only that we usually anticipate the wrong things, because we don't see the full picture yet. In my opinion, the only way to learn this is to force yourself to implement "lean" and experience what happens. Do pair programming, do code review, and try to remember each other of your learn philosophy. It will become easier over time. And you will experience that it works.

"Empower the team" is imminent in Scrum. "Deliver as fast as possible" comes from "decide as late as possible"/"Simple Design" + Scrum's "get one thing Done before you start the next". "Eliminate waste" is closely related to "Simple Design"; if you implemented to much: don't be afraid to throw is away. Pair programming/reviews "amplify learning" incredibly much; also give developers time to read about Clean Code, Refactoring, ..., and to practice it.

Answer 5

1 Eliminate Waste - Find a way to measure what is wasteful (unused features, incomplete features, rarely used features, communication failures, handoffs etc), whatever isn't adding value to the end result.

Measuring waste is probably one of the easiest places to start and in my experience waste is one of the biggest drains on any software development project. It permeates the highest level of user facing functionality to the deepest levels of unnecessary code. The trouble is no one ever likes to remove functionality, so it just builds up like cancer over time. The sooner it's removed, the sooner no one will have to wonder what its value may be.

Start out measuring application usage in high level areas. If you notice low usage, expand your monitoring in the relevant area. Once you identify areas of unnecessary functionality, plan to remove it, and then figure out how it came to be in the first place. Chances are unnecessary functionality came from another form of waste, like an initial communication failure or decision making handoff.

Of course, don't get crazy, make sure your investment in identifying waste is reasonable and not waste itself :) as returns diminish, don't keep investing in higher levels of monitoring... eventually you can shift the ability to identify waste to be upfront in avoiding communication failures and handoff, thus negating the need for monitoring after the fact.