Kanban

I've worked with Scrum for a while, having gotten my CSM certification in 2005, and I've spent time both before and after that trying to learn what I could about Scrum, agile, and Lean, both in the context of software and out side of it. After absorbing bits of information on Kanban informally, I decided that to was time to read a book on it. I read David Anderson's book Kanban: Successful Evolutionary Change for Your Technology Business.

Anderson's book was a good introduction to Kanban in practice. It had a mix of stories, theory and guidelines that gave a good sense that the content of the book was based on practice. My only reservation about the book was that while it was well written in many spots, there were places where it was a bit less focused that I would have liked. But if you are willing to skim through the less tight parts of the book, it is worth a look. Here are some of the things I learned while reading Kanban.

Before I read about Kanban in detail my initial impression was that  people new to agile, who didn't find Scrum appropriate for their project, were enthusiastic about Kanban because was that they were unwilling to be disciplined enough to manage their work queue. It's hard to move from one's current approach (either a long term rigid planning approach, or chaos) to an approach that required the discipline to work in the context of shorter term commitments (Sprints). With Kanban, you can think in terms of a stream of work. Problem solved!  Or at least hidden. I'm now beginning to understand that, while it might be true that some people and teams are enthusiastic about Kanban over Scrum for reasons like this, that's not all there is to it.

Much of what I learned in Anderson's book about Kanban sounded familiar (not surprisingly) based on what I know about other agile methods. You can use an entirely Kanban-based approach to a project. But, there are elements of Kanban that you can overlay, on say, a Scrum project. The concepts such as limiting work in process (and making that limit explicit) seems line with that Scrum teams I have worked on have done. Scrum teams can certainly benefit from a deep understanding of Kanban principles much as a Scrum project is likely to fail without applying technical practices such as those of XP. (For more a more in depth comparison you can have a look at the article by Henrik Kniberg and Mattias Skarin
on infoQ,  )

Kanban is less structured than Scrum in terms of boundaries and commitments. While in some sense this sounds promising for teams that wrestle with "interrupts" like "critical production issues" it also means that there is less of a framework to identify and address the underlying problems, and the path to improving your process might be slower.  Kanban can be useful. If you use your imagination, you might even think that Kanban is the limit of Scrum as iteration length approaches 0. If teams have trouble managing 2 week iterations, they are likely to have problems with no iterations. At least until teams internalize agile practices and values fully, Scum is probably still a better fit for teams wanting to adopt agile.  (See  Ken Schwaber's comments for a more strongly worded view on this).

While there are aspects of Kanban that will inform my Scrum practice, I think that for those trying to adopt agile, Scrum is a better approach. Kanban might seem to work well, and present less of a barrier to managing a hard to manage backlog, but keeping work in line and maintaining the sustainable pace and slack that  both Scrum and Kanban advise can be much harder. Rather than being an easier way to agility, Kanban seems to require more discipline, and starting with Kanban might not the the right answer for many teams.




 

Do we care whether it's Software Engineering or Craft?

Much like a tenet of agile software development is that "planning is more important than the plan," there are some questions about software development that are useful to explore, even if you can't suggest a good answer. One of these these is whether what we, as software developers do, is (or can be) engineering.

I was talking with a colleague about a comment someone made about a post about lessons that software engineers can learn from artists. In this comment the poster raised an issue that comes up a lot when someone uses the phrase "software engineer." The question was, in essence:

Is what we do when we build software "engineering" or "craft?"

My colleague, who has a background in Naval Engineering and who is engaged to an Electrical Engineer (who designs and builds hardware) suggested that the difference is that one rule of thumb might be:

It's engineering if you need to use calculation (about physical constraints).

An example was that to build a bridge you need to do calculations to determine if the bridge, as designed, will support the load you want to support. Many of the "classical" engineering disciplines (Mechanical, structural, electrical) fit that criterion. But by that definition, some things which most would agree that are crafts, such as carpentry, involve calculations. So there is probably more to it that that.

On the other hand, I don't think that all work that is in a discipline that we might call "engineering" is engineering. A good friend designs test equipment for a living. When he builds a sensor to measure the performance of his home heating system is he doing engineering, or is that activity more like a hobby or craft?

As I think of the question, and the frequency at which it comes up, I wonder:

Why does it matter whether we are software engineers or software craftsmen?

Engineering, to me, implies a certain level of discipline are repeatable process, and all of the classic engineering disciplines are grounded in physical laws that we are fairly confident in for the scales at which they apply.

If the "software engineering" question is important to you, take a minute to understand why you are asking the question, as the reason for asking may affect the answer.  You can bring discipline to building something you regardless of whether or not you are engineering. I don't think that the question of how (or whether) to make software into an engineering discipline is an unimportant one. But I do think that it is often asked in a vacuum, much like the an attempt at a user story that is missing the "so that..." clause.

To me, as a professional, it's more important that I bring discipline to what I do. I want to build useful, quality, software where the definition of "quality" that is often most appropriate is Jerry Weinberg's from Quality Software Management: Systems Thinking:

Quality is Value to Some Person.

It might be fair to say that we're not always "crafting" or "engineering" software when we sit down at an IDE and program. Sometimes we're just coding (or hacking, or programming). But if you (and your team) are committed to building software that meets your customers needs, and you are always working to learn how to work better, you're doing a good thing. And you don't need to call it engineering to acknowledge that.

Agility (and Learning Opportunities) Everywhere

People often ask "can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is "but can my type of project really be structured in an incremental way?"

While in general, I tend to believe that the answer is "yes," it's always good to have examples. So I was intrigued to head a segment on the radio show Living On Earth, where the rapper Baba Brinkmann described his approach to developing The Rap Guide to Evolution as "Performance, Feedback, Revision," which is a very concise way to describe an agile approach. This meta-aspect of this also intrigued me, as Brinkman used the performance, feedback, revision theme in the evolution rap as well.

This is also another reminder of how software developers can learn much from many seemingly unrelated domains. As Rob Austin and Lee Devin explore in Artful Making: What Managers Need to Know About How Artists Work managers, including software managers, can learn from theatre, and in Computers as Theatre Brenda Laurel discusses what interaction designers can learn from theatre.

So, yes, you can be agile if you are doing something other than software, and if you are developing software you can learn how to build software better by looking at other disciplines.

Questioning before Answering

The other day I came across a short video in which a parent is faced with answering a unexpected question posed by her young child. I found this video amusing because, being the parent of a kindergartener, I expect to be faced with many awkward moments like this in the future. I also found it an interesting metaphor for software requirements gathering.

In the video the  parent could have answered the question a whole lot more simply has she just asked taken a moment to try to understand what the real question was, and not taken the question at face value. (I'm being purposely vague at this point in case anyone wants to watch the video.)

Most of us have been on projects where much effort has been spent in an attempt to solve a customer's stated problem, only to discover that that either:

• The program didn't actually solve any of the customer's real problems.
• The team didn't solve the problem that the customer wanted solved.
• There was a much simpler solution.

I'm not suggesting that exhaustive requirements capture is the answer. Nor am I suggesting that you should not start building software until you have complete understanding of a problem. The reason that agile methods work well is that they  acknowledge uncertainty, and provide a simple path to refining understanding: evaluating working software.

Acknowledging uncertainty does not mean ignoring information. In some cases customers might not really understand what they need, and the best way for a team to progress is to take a guess based on the information they have, and iterate on a working system.  In many cases a customer will know the reason they want to do something, but may not be able to step back enough to express it. In these cases, but not trying to ask "why?" your team is ignoring information  that can help them do their work. In more cases than not, a customer can fill in the pieces of  the user story template:

As a (ROLE) I want to (DO SOMETHING) so that (REASON)

and provide insight into the problem that she wants to solve. This will save time, effort, and help the team deliver a better system.

If your team takes customer requirements statements at face value without exploring the reasons why a customer wants a piece of functionality, they aren't holding up their end of the collaboration part of agile software development. 

Had the parent in the video though to ask why the child asked the question that she did, the process of answering might have been simpler.

SCM Tool as Collaboration Tool

A few weeks ago I had the opportunity to give a virtual talk at a product launch for an SCM Tool vendor.   The theme of the talk was basic branching strategies, and preparing for the talk led me to reflect on what  Brad and I wrote in the SCM Patterns Book. This post is based on those thoughts.

When Brad Appleton and I wrote Software Configuration Management Patterns I wanted to focus on how to use Software Configuration Management and Version Control  to improve productivity and collaboration.  In many organizations SCM processes, procedures, and policies are focused on stakeholders other than those who rely on the system most: developers.

A good SCM process can help you to work better as a team, and help your team be more agile. An ineffective one can slow down development, and be an obstacle to progress. Likewise the tools you use, while secondary to the decisions about the way you work, can affect how effective your SCM process is.

Tools are important. A good SCM tool helps you work more effectively as a team and allows you to focus on your work and not the mechanics of the SCM process. But the process needs to come first to use SCM effectively. Here are some brief thoughts on what I think are the core issues to consider when designing an SCM process.

Code Lines

While there are many aspects to Software Configuration Management, the first concept that comes to mind for many is version control. Developers commit changes to a code line, and update their workspaces from a code line. The main role of an SCM process is to facilitate integration, and you want commits and updates to be frequent to avoid complicated integrations.

Frequent commits also give developers the full benefit of having a history of their work so that it is easy to revert to a known state when a coding experiment goes wrong. So you want processes and policies that encourage frequent integration.

The simplest SCM model is to commit changes into a single code line. Working on a single code line is simple in some ways. But it requires discipline to keep a single code line, with frequent commits, stable.

A code line where people have practices such as tests and a discipline of pre-commit builds in place, is an Active Development Line. Not every team can maintain this discipline. And even for those who can there are legitimate reasons to work on more than one code line. Once developers realized the challenges of working on a single codeline, they quickly become interested in the  way a tool supports branching.

Branching

The first question people often ask about a tool is how it supports branching, this question is best answered in the context of  understanding why you want to branch. Branching is a technique for enabling parallel development. When you branch you create code line that is a copy of its parent and it can evolve independently. A Branch allows you to work on variation of the code without affecting or being affected by, changes in  the parent code line.
 
The ability to work in parallel can be an effective tool for enhancing productivity. It can also be a cause of bottlenecks and frustration. The difference between the two results depends on whether you follow branching patterns that address the problem that you are trying to address.

Branching can be a very useful mechanism for making your development process more effective if you do it the right ways, with the right tools, and for the right reasons. A poorly applied branching strategy can have the opposite effect, decreasing your velocity and making it harder for team members to work together. So while how a tool supports branching is important, it's more important to understand why you are branching, and if branching is as helpful as you'd like. As I explain in more detail in a article on TechWell:

Branches are helpful if the enable you to work more quickly than a single code line would.

To make this concrete, here are some examples of solutions to a "fix the release" scenario:

• Use a Release Line: A common branching pattern is to create a branch when you release software, The Release line allows you to deliver fixes to the released software quickly without having to worry about the impact of new development work on the code. Most of the time a release branch is the right choice for managing changes to a release. There are alternatives, but each adds its own cost. 
• Defer the fix until the next release is scheduled. This will only be a viable option if the problem isn't critical, or if the team releases software frequently. In many cases, teams don't release software frequently enough to do this. 
• Fix the problem in the existing code base and release early. This can work only if you have a continuous quality assurance cycle that insures that your code is always ready for release, While many teams strive to do this, few are able to.

So, in many cases, the traditional Release Line pattern is the right choice. But it's good to be aware of alternatives.

Distraction

While branches can be useful, they have costs that you need to be aware of. Team Software development is a balance between integration and isolation. Branching can be a powerful tool for isolating change.

But be aware that not all changes are are isolated as they first appear. For example, much of the time when you fix a problem on released code, you will also want to address the problem in your new development code line. So by working on a branch you have created the need to do the same work twice. And the more branches you have, the greater  the risk of distraction, and reduced velocity.

Software configuration management practices and tools are part of a developer's basic toolkit. Like all tools, the right tool used correctly they can help you get your job done. The wrong one used without understanding can distract you from your goal.

Branching can help improve your velocity, but be sure to be aware of the reasons you are branching, and always ask your self if the branch will  deliver enough value to justify the cost. and always test and integrate frequently to avoid surprises.

Keep in mind that the real goal of an SCM environment is to help your team to work effectively.

Definitions

The other day a colleague use the phrase open interval to refer to time periods that included their endpoints. This didn't sound like the definition that I'd learned in analysis class, which I will admit was not my favorite subject in grad school, so I searched for a definition and found:

An open interval is an interval that does not include its end points.

This led to a brief, but interesting, discussion about why my mathematically-minded colleague flipped the meanings. It came down to the feeling that the definition didn't make sense in terms of common english usage (when you open a door, or a group, for example, you're being inclusive).

Definitions add precision, but when you use words that have meanings in multiple contexts, you can find yourself in confusing conversations. Consider a term like normal, which can be defined as:

a lack of significant deviation from the average

This sounds pretty benign, but people often carry around more that just definitions when they hear words. Using "normal," for example, in conversation can get tricky if the group you are in has not established a baseline context;  even though there is no value judgement inherent in the word, people might assign values to being more than a certain distance from the average. And then rather than than discussing the problem at hand you get distracted by a meta conversation.

The same is true when you're adopting new engineering practices. Consider a word like refactoring, which has a precise meaning and that people often use to mean "change." When adopting agile methods, you might have a discussion about how many of the practices that you need to follow to be able to say that you are using a method. Can you do Extreme Programming as a solo programmer when Pair Programming is a practice, for example?

The discussion is very interesting and useful, as it leads to an understanding about what is useful about XP practices. But from a definitional sense, I would err on the side of saying "No, XP is defined as the practices, but you can be doing something XP-inspired."  The question you want to ask is "why does it matter if I'm doing XP (or Scrum, or another process)?" Maybe it doesn't. Unless you want to learn the value (and limits) of a practice.

The discussions get more interesting when it comes to concepts like "agile" which are very overloaded in different contexts. You can be more agile from a business perspective, yet not follow a defined agile software development method, for example. But if you want to say that your team is agile, be sure that you understand what your definition is.

Doing an "inspired by" process can be good if you are getting the results you want. When you are learning a process, it's important not to customize the practices until you understand why they are in place. And when communicating with others, being a bit fussy on the definitions (or qualifying your description) can be helpful.

Definitions help us to communicate. It's a useful default to stick with the definition in the domain. Then apply value judgements as needed. It seems better to say that you aren't agile, yet getting better results than you were, than to morph the definition of agile so that it fits your practices. Making "Agile" a checklist item itself is counter to the principles of agile. Define what you do in terms of your practices and evaluate effectiveness in terms of your results.

Words and definitions help with communication. And it's hard to come up with an unambiguous word. But try hard to use words as they are defined in your context. That will help you to communicate, set expectations, and maybe even be more agile.

Refactoring

Frank Buschmann wrote a 2-part article in the July/August and September/October issues of IEEE Software that covered an important aspect of software development: refactoring.

Yes,  you'll hear the word "refactoring" spoken often in any development team, but most developers rarely discuss what refactoring is, and whether they are refactoring or doing something else, like "reengineering" or even re-writing.

I won't repeat what Frank said, as he said it quite well,  but as I read the article I realized that there are some points that get lost in many teams and are worth emphasizing:

• Refactoring does not mean "any kind of changing." It means changing the structure of existing code to preserve functionality. In principle you are making the code "better."
• To refactor you need a way to validate that you have preserved functionality. Automated tests are probably the best way to do this. I suggest that you can't refactor without having a test plan in place. And from a practical perspective, this means automated tests.
• Refactoring is a way to improve code quality, but like other things a development teams spends time on,  you you should refactor when it provides business value. 

Being precise about when a change is refactoring and when it's reengineering, a rewrite, or simply changing code to add a feature helps set expectations with stakeholders and helps you as a developer better understand when you'll be done. And by thinking in terms of refactoring continuously you can deliver code more quickly, and avoid the need for reengineering or re-writing, and better be able to evaluate functionality with incremental delivery.

Refactoring is good. Not all good coding is refactoring.