Net Objectives

Day 15 of 100 Know You Are Managing Time to Market & How To Do It

alshall — Fri, 17 May 2013 14:45:36 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development

The purpose of development/IT is to deliver value quickly - not just for a team, but for the entire organization. If you reflect on this, it's not about going fast, it's about removing delays. Delays are typically waiting for folks, getting feedback late, detecting errors late, or just going to work on something else that has come up. Scrum, XP, and Kanban all, in their own way, focus on doing this - eliminating delays. However, instead of listing how these methods do it, let's look at fundamentally at what practice they use to do it. There are (at least) four ways to accomplish this:

remove delays in the workflow by making them visible on a value stream map (Lean)
manage work-in-progress to remove delays in the workflow (Lean, Kanban)
use cross-functional teams that self-organize to remove delays in the workflow (Lean, Scrum, XP)
focus on business value delivery - do what it takes to get the most important thing out the door fastest (Lean, Scrum, XP, Kanban)

These are obviously related, but since one-size does not fit all, if you don't know all of these methods you will certainly not be effective in certain situations.

Let's go through each of these briefly:

Remove delays in the workflow. Sometimes mapping out the workflow is all it takes to get to the root cause of problems. Attending to delays and thrashing at a macro level can lead to insights how to remove them. Acceptance Test-Driven Development is another method to remove delays.

Manage work-in-progress to remove delays in the workflow. Many (most?) delays in workflow are due to working on too many things. If you manage the size and number of things being worked on, the delays you want to eliminate will be reduced significantly.

Use cross-functional teams that self-organize to remove delays in the workflow. Scrum works, when it does, because its core mandate of a cross-functional team provides the structure from which to eliminate delays in workflow. Having all the people you need to get the job done makes it relatively straightforward to eliminate any delays in the workflow. Scrum hits the wall when it is attempted to be used across teams because it provides no viable mechanism to handle cross-team delays.

Focus on business value delivery - do what it takes to get the most important thing out the door fastest. If one focuses on delivering business value, one will do what it takes to:

eliminate delays in the workflow
will focus on the most important work - managing how much work is being done to not lose focus from the most important stuff
will have all the people necessary to get the job done quickly (notice what you do when you have a high priority, severity one issue

These are essential the first 3 items on the list.

The bottom line is don't get hung up on your method - understand why each can work and use them when that practice is most effective.

Want to learn how to do this in your company? Send me a note.

Al Shalloway
CEO, Net Objectives

Take the 100 in 100 Challenge. I'm committing to add one entry each day. I'm asking people to accept the challenge of reading them. If you accept this challenge, please enter a comment on the blog that started it all and tell me why you are taking up the challenge - that is, what you'd like to learn

Author:

alshall

Day 14 of 100 There is more than customer value

alshall — Thu, 16 May 2013 04:23:52 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development

While adding value to the customer is the ultimate goal, there is more than customer value. There are actually at least five different types of business value:

knowing what will be of value to the customer
knowing how to build this
building this
deploying this value so it is consumed by the customer
being able to do any of the above faster

All of these are of business value. The last one is valuable to the customer and can provide a unique selling proposition to them. For example, a company may not have the most features, but if they are in a position to add new features faster when requested, they may be more attractive to customers than businesses with lots of features (many likely not used) that can't add new ones quickly enough.

If you are doing Scrum and you realize that the team should be about delivering business value every sprint, many insights present themselves. When one is not able to deliver quickly, one still wants to discover and build thin, vertical slices of functionality quickly. If one is doing Kanban and there is no timebox, the need to deliver business value quickly requires you to slice stories up into smaller chunks. One should not build what one is not sure of.

A customer centric focus is a good thing since it keeps the customer in mind when we are building our software instead of looking at the systems we are building. Software, in itself, is useless. It becomes useful only if it assists the customer. But that does not mean we don't have value in learning how to achieve customer value.

Enjoy, and, of course, ask questions on our user groups.

Al Shalloway
CEO, Net Objectives

Day 13 of 100 Systems Thinking From Individual to Organization

alshall — Tue, 14 May 2013 12:49:49 +0000

Hi everyone. To pick the pace back up I'm going to write either shorter blogs or, as in today, I will take some previous work and mold it into this work. I appreciate your patience and will get things going again.

Continuing with the 100 Things You Must Know to Be Effective In Software Development

I believe that one of the essential components of successful Agile adoption across teams is systems thinking. “Systems thinking” is the process of understanding how things, regarded as systems, influence one another within a whole. In software development, this means looking at: product selection, product prioritization, requirements, architecture, design, code, test, quality assurance, delivery, integration, management, HR, and more. In other words, it means looking at the development workflow as a whole. Optimizing one part of the workflow may have no impact overall and can even be harmful to the whole.

Lean offers a particular way to look at the system: the value stream. The value stream is the flow of work from when an idea is first conceived through implementation, deployment and eventual use or consumption. The time from start to finish is called “cycle time.” Lean thinking says that actions that lower cycle time are usually good and those that lengthen cycle time are probably not. Lean thinking looks for ways to remove delays which results in eliminating unnecessary work. This leads to improved quality and lowers costs.

When multiple teams and products are involved, this holistic approach extends to the entire set of projects being worked on. For example, it may be that delaying one project is worthwhile if another project can deliver more value, more than the cost of delaying the first project. This gives us helpful questions for deciding whether to start a new project: “Will this new project add to the value being delivered?” and “Will adding this project slow down or negatively impact the ability of existing projects to deliver value?”

While systems thinking is essential for scale, it is also useful in the adoption of Agile at the team. Here's a blog from August of last year that discusses how systems thinking can be useful when difficulties in adopting an Agile method arise:

August 31, 2012 — Posted by Al Shalloway

At Net Objectives we’ve trained tens of thousands in Scrum and Kanban. We don’t really play sides in which method we use. Our own experience is that hybrid methods are typically needed in large scale transitions – which is our specialty. Regardless of which method our clients employ, we always suggest a system-thinking approach within the context of Lean-thinking.

Lean-thinking is actually a kind of systems thinking. It suggests that most of the problems that are encountered are due to faults in the system. That we should not blame people for errors, but rather look to see how the system they are in is working.

A variant of this would be to look how a systems thinker would approach the problem of Scrum-but and Kanban-but. As an aside, I want to point out the Kanban community discourages the use of the term Kanban-but since it focuses on the people aspect of not doing Kanban. Systems thinkers would also discourage the use of Scrum-but as a derogatory term for the people not doing Scrum properly. He wouldn’t suggest that people are doing Scrum-but because they aren’t motivated enough, he would ask “why are they not doing Scrum properly?” Is it they don’t understand the benefit of the Scrum practice they are not doing? Is it that it would be too difficult to do it? What is it about Scrum itself that contributes to these challenges?

By focusing on the system, we avoid putting the blame on the people. Now it may be that the people aren’t motivated enough. But as soon as you draw that conclusion, you have lost all power in helping them. It is one reason the Fundamental Attribution Error is so deadly and being aware of it can be so powerful. Regardless of whether the judgment is true, once it has been made there is little that can be done.

Instead of finding what is wrong with someone that is not doing what they are supposed to, systems thinkers look for what the people experiencing challenges are looking at (or not looking at) that has them make poor choices. We assume they are a good, intelligent, motivated person looking at the wrong things and therefore making bad decisions. Not that there is something wrong in their character such as a lack of motivation or persistence or courage.

In software development, the “system” is often the workflow they find themselves in. In other words, if we’re talking about a developer, when do they get the opportunity to talk to customers, to testers? Do they get requirements and the validation for these requirements at the same time via Acceptance Test-Driven Development or not? These are choices often outside of their control.

My suggestion is that if you are using a method that has a common set of challenges, that perhaps one should look at modifying the method to avoid the challenges instead of trying to motivate your people into putting more effort into overcoming them. I’m not suggesting motivation isn’t important – it is. And sometimes working harder and having more courage is the only route to success available. But my experience is that people in this field are very motivated. The question is, how can we best take advantage of that motivation?

For more on systems thinking, I highly recommend The Systems Bible by John Gall.

Day 12 of 100 How to Avoid Redundancy: Shalloway's Principle

alshall — Thu, 09 May 2013 22:12:27 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

I really appreciate the 2-3 new people who commented on the day 0 blog and joined our group. It got me to write today's entry on the flight home from the Scrum Gathering - something I almost certainly wouldn't have done otherwise. So keep reading and getting friends to join - it helps.

I've been wanting to do a technical one again and thought I'd do one based on Shalloway's Law and Principle. There's a short version of this here and a long one - the Shalloway's Law chapter from our book Essential Skills for the Agile Developer: A Guide to Better Programming and Design.

Enjoy, and, of course, ask questions on our user groups.

Al Shalloway
CEO, Net Objectives

Day 11 of 100 If You Tell the Chicken and Pigs Story You Will Not Scale

alshall — Mon, 06 May 2013 18:52:49 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

The Scrum Gathering starts in Las Vegas today where I am presenting a talk this afternoon. Figured I should do a Scrum based lesson today. I have been saying for years that the Chicken and Pigs story is counterproductive and is a symptom of an over-reaction to management. I wrote a blog about this Is Chicken and Pigs Counter-Productive. I decided to just point to the blog instead of re-writing it because I think it is interesting to see how Lean-Thinking and Lean-Management seven plus years ago lead to thinking that you are now seeing manifested in the Scrum community.

While avoiding interruptions is critical, thinking that management is the cause of them all and we must protect ourselves from management is a short-term solution, a long term trap, and an attitude that will make it harder to learn good methods to include (and possibly transform) management. In the blog pointed to I ask the question if the "chicken and pigs" story was still being used. I am happy to say that its use is significantly down 7 years later. But it's important to eliminate it entirely.

Al Shalloway
CEO, Net Objectives

Day 10 of 100 Know Why and How to Estimate

alshall — Sat, 04 May 2013 16:47:22 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

I've been hearing two disparate views of estimation, and it does feel "camp" oriented. The Scrum camp doesn't question estimation but is looking for better ways. It takes much more time than it feels it should. The reason for this feeling is that it takes much more time that it should. Planning poker is useful in some situations, but for the very reason it is effective in some, it is very inefficient in most. If you need to get folks to talk, use Planning Poker. Otherwise, there are two other methods that are much more efficient and just as good or better. These are James Grenning's Planning Poker Party and Steve Bochman's Team Estimation (from our Lean-Agile Pocket Guide for Scrum Teams and Lean-Agile Software Development: Achieving Enterprise Agility on our books page). Both are much more efficient because they use relative estimation (i.e., you first compare the stories/features with each other, making similarly sized groups) and then you assign them values.

If you are in a maintenance organization, planning may be unnecessary. But if you are wanting to plan out multiple releases and take advantage of team-members whose skill set/abilities/experience is in high demand because few have it, estimation is often essential. The mantra of "no estimation" seems to me to be a reaction of inefficient methods in the Scrum camp and an over-enthusiasm for the Lean mantra of eliminating waste from the Kanban camp. Actually, I don't like "eliminate waste" as a Lean Software Development mantra. It is too easily confused and taken up by folks who aren't really clear what waste is. Not all planning is waste. Not all estimation is waste. It depends how you do it.

I believe one must look to the stakeholders to truly see if estimation must be done. In many situations it doesn't need to be done for them. In some situations it is actually useful for the team. If teams are wanting to not do estimates because of what management does with them, then we have a problem between management and teams. Just avoiding the estimates doesn't solve the problem. Always go to what you are trying to achieve and why when looking at practices you are undertaking. If estimation is taking more time than it's worth, see if there are more efficient methods than what you are using. Don't throw out the baby with the bath water.

Al Shalloway
CEO, Net Objectives

Author:

alshall

Day 9 of 100 Pickup Sticks and Trim Tabs

alshall — Fri, 03 May 2013 19:51:28 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

Relatively early in my consulting career, I realized that it’s not simply the low hanging fruit you go after, you have to attend how one thing sets up another. As people learn, some lessons set up others. I call this the “pick up sticks model for building curriculum.” Some practices also change the environment within which people work in such a way as to greatly leverage your efforts – these are trim tabs. These two concepts create the opportunity for very powerful insights on how to manage transitions. Read about both in Trim Tabs and Pick Up Sticks.

Al Shalloway
CEO, Net Objectives

Author:

alshall

Day 8 of 100 The Fundamental Attribution Error

alshall — Thu, 02 May 2013 02:58:32 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

This blog is going to be as much (or more) personal than technical. I had already listed The Fundamental Attribution Error on this list. But I had a great experience (and insight) today that I wanted to share. First, a quick summary - the fundamental attribution error describes the tendency to blame the character or disposition of a person for their actions instead of recognizing that their behavior is more due to the situation that the person finds themselves in. This is an important insight when making organizational change. Lean is based on Edwards Deming's work, in particular his belief that most (96%) errors are due to the system people find themselves in and not due to the people themselves. He mandates that managers improve the systems and be held accountable for that. He accuses managers of abdicating their responsibilities when they just implore folks to do a better job when the cause of poor work is the situations the folks find themselves in. These situations are usually outside of the control of the folks doing the work. A simple example is testers being overloaded with work but not being in a position to determine when they are involved.

Agile has helped solve this problem by putting much of the process in the hands of the team - a good thing. But in larger organizations management's role is bigger and can't be ignored. Understanding the real source of problems is critical.

Anyway, I spent the day watching and participating in my son's graduation from the police academy - he is now a King County Deputy Sheriff - I am also particularly proud that he was #1 overall in his class of about 35. Spending the day with new police and sheriffs and seeing their families, wives, girl friends, boy friends, ... really impressed on me how a few bad experiences I've had with police (personally or read about) had me just say - "oh, police are like that." Clearly the fundamental attribution error. First of all, it was clear that virtually all of these folks were really great, motivated people. Now, I don't doubt that at some point some of these folks are going to do some things they shouldn't. Don't get me wrong here, I'm not justifying that. But every profession has folks who do some things they shouldn't. That doesn't make that industry bad. It also may be due to the situation folks are in. And that's my point, if these folks are great starting out, what has some of them be not so great later? Again, not excusing it, just saying we need to look beyond the individual and see what influences the individual.

This all got me thinking in a couple of ways - first of all, appreciate the situation your police/deputies are in. Second, recognize that although that is an extreme case, it's similar to folks with less dramatic jobs in your own company. In other words, walk in their shoes before judging. Understand that the situations are often the problem. We need to change the situations, not the people's character. Perhaps ask yourself - "what would have an intelligent, motivated person act like that?" It will almost certainly provide insights.

And, if you hadn't clicked on it before, read about The Fundamental Attribution Error (at least the first 2 paragraphs).

Al Shalloway
CEO, Net Objectives

Author:

alshall

Day 7 of 100 Emergent Design

alshall — Tue, 30 Apr 2013 15:49:01 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

I appreciate the comments I've been receiving on this project. While I am not changing the title as yet, I believe it would be more appropriately named: "The 60 things you need to know, the 10 things you need to forget and 10 other useful things to be effective in software development." A bit long, I know.

Today I want to talk about technical issues. Many people wonder how they can go to Agile. The two biggest concerns are that Agile will have us design ourselves into a corner and that without high tech debt, we need to make changes in large batches so as to enable testing. I'll start with the second concern first: Going Agile is not causing this problem, going Agile is exposing it. If you keep adding to your technical debt and don't automate your testing your software will eventually die! True, one must be intelligent about any transition. But ignoring the need for the transition can be deadly.

As far as designing yourself into a corner that can be avoided with the use of emergent design. It is unfortunate that when Agile first rose in popularity, many technical thought leaders talked about design being dead. This has since been recanted, but the idea that we can just do the simplest possible thing and proceed without fear remains in the minds of many. Emergent design is about how to only build what you need now while preparing for changing your design when new requirements demand it.

Here's a Primer on Emergent Design, a short blog I wrote recently that describes what you need to know.

Al Shalloway
CEO, Net Objectives

Author:

alshall

Day 6 of 100 Coordinating Teams With Backlog Management

alshall — Mon, 29 Apr 2013 14:49:46 +0000

Continuing with the 100 Things You Must Know to Be Effective In Software Development.

One of the big banes and puzzles in Agile has been how to coordinate teams. Scrum of scrums is still being espoused even though its track record is worse than abysmal. Much of the reason for the insistence on a team of teams coordination model is due to:

the lack of understanding the importance of a holistic view
not truly appreciating the tribal nature of folks
misunderstanding the role of management in Agile

I will quickly cover these before pointing to an article that provides an example of multiple team coordination in an Agile space. Later chapters will provide more information on these topics.

An holistic view is needed. Agile software development is about delivering increments of business value, not team iterations. A bigger picture is needed. Effective, efficient teams are only part of the picture.

Folks are tribal. Part of respecting people is to recognize that they are tribal in nature. They will care more about their team than other teams. This is not selfish or an indication of something wrong in the company's culture. It is just the way things are.

One of management's role is to create the big picture. Many agilists are managerphobic. While micro-management is not good, absent management is also not good. Managers need to create the bigger picture within which the teams work because the teams will have a very difficult time doing so.

See Coordinating Teams With Backlog Management to learn the basic approach taught via a case study.

I assure you methods like this work. They are guided by the principles of software development flow.

Al Shalloway
CEO, Net Objectives

Author:

alshall