Topic: Agile Development

What’s the value of Agile out of the box?

Michael Walkden, Tuesday, January 12, 2010 @ 10:24 pm

I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to explain to customers. While I was reading Leading Lean Software Development I discovered something that helps. The Poppendieck’s point out that the engineering practices of Agile (TDD, collective code ownership, etc…) are solid and not likely to change. But, the project management practices implement a system on top of another system - a hack.

Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.

Photo Credit:
kevindooley
under a Creative Commons Attribution License

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Review: Leading Lean Software Development

Michael Walkden, Sunday, January 10, 2010 @ 8:10 am

In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.”  If you are completely new to agile and lean you the book might move a little fast for you.  If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.

If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency.  These companies make money to survive rather than simply surviving to make money.

The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.”  A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.

Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.

Conclusion

I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

The Dog Ate My Software: Agile is not Undisciplined

Dietrich Kappe, Monday, January 4, 2010 @ 5:00 am

photo credit: LKaestner

Back in college I used to work at the main campus computer center. That was back in the days of time sharing Unix and mainframe computers, so it was a great way to get some extra CPU time for my various projects. Besides locking up at closing time (I loved to work the 10pm-3am shift), I had to change toner cartridges, support the brick macs, windows 3.1 machines, and the various Unix and Mainframe terminal users.

Over time, you learned to identify various user types. The vast majority of users had simple "hey, how do I do this" or "this ain't working" types of issues. Of the rest there were two main problem user types: the "helpless bunny" and the "walking crisis."

The Bunny displayed profound helplessness in order to get you to do their work for them. The first time I had a Bunny, I was caught unawares and spent the better part of my shift formatting their document in Wordperfect. With subsequent Bunnies, I used tough love and gave them manuals and man pages to read.

The Walking Crisis was typified by the grad student who waited until the last moment to add end notes to their masters dissertation, and dammit, if they were going to suffer, you were going to suffer. Their technique was to try to convince you that their problem was your problem, i.e. the fact that they couldn't do two months of work in five hours was a shortcoming of the software, and thus a support issue.

The more enthusiastic you were about helping users, the more susceptible you were of being dragged down by the Bunny and the Crisis.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

You Shall Know Our Velocity!

Bernhard Kappe, Friday, December 18, 2009 @ 7:09 am

With apologies to Dave Eggers, this post is not about traveling around the world in a week to give away $32,000, but about measurement and agile development.

One objection to agile development we get sometimes from people who have never done agile is that it sounds too undisciplined, unstructured and risky.

Would they say the same thing about lean manufacturing or six sigma?

They're confusing agile with cowboy coding.

In fact, like six sigma, agile software development is explicitly about reducing risk, measuring efficiency and continuous improvement.

The old management adage of “You can’t manage what you don’t measure” holds true in software development as well. If you have no feedback loops, and you’re not measuring and improving, you’re not really doing agile development.

The core measurements we use are story points and velocity.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Your SDLC or Your Product – You Decide

Michael Walkden, Wednesday, December 9, 2009 @ 10:33 pm

…or the telephone game

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Fake Agile: All of the Symptoms, but not the Disease

Dietrich Kappe, Monday, December 7, 2009 @ 12:56 pm

photo credit: Ramón Peco

For any software development professional who has contracted out from time to time, this story must seem familiar. You interview and are told that they practice agile development. Once you show up at the job site, they tell you they practice their own "brand" of agile, which turns into "sort of agile" or "we've take the best parts of a couple of different methods" or "it isn't exactly" -- wild and crazy hand gestures -- "XP."

It's a classic case of people following the form or ritual of a process without understanding the why of it. Take the morning scrum, for instance. The ritual around these usually calls for them to be done standing up. We've of course all heard of the standups that run an hour or two. Someone on that team doesn't understand the function and is following the ritual.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Advice to Developers: Try Understanding the Business

Dietrich Kappe, Wednesday, November 25, 2009 @ 1:47 pm

The flip side of my advice to business people to start treating your developers like adults is that developers have to start behaving like adults. What does that mean? Well, my point is that in order for business people to include developers in business discussions, developers have to be ready and willing to understand and participate in those discussions. And that means a little bit of homework.

For developers to understand why this is important, just think about the client/stakeholder you've worked with who has been the most willfully ignorant of the software development process -- the sort of client that demands things that are hard or impossible to do with software and then throws a tantrum when someone tries to explain this to them. Who wants to work with that person? No one. Think of how ineffective that appdev team is with this person gumming up the works and whipsawing the team with unreasonable demands.

Now put yourself in the shoes of a business person who is dealing with developers who are ignorant of basic business concepts. Why would you entrust such folks with any degree of authority for developing a new software product for your company? You wouldn't.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Innovation and Treating Developers Like Adults

Dietrich Kappe, Monday, November 23, 2009 @ 5:28 pm

Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
-- Tom Smykowski

photo credit: sdminor81

I get a lot of grief when I talk about agile practices and how it ends some inefficiencies, i.e. less personal activity during work hours by developers. One commenter on my last article on the benefits of pair programming put it thusly:

It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

He's right, but not for the reason he states. Pair programming is still better than solo programming in almost all cases. Treating developers like children, however, is a sin that is pervasive in many businesses. In my advocacy for pair programming, I was subconsciously pitching my message to product and development managers in large organizations.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Under the Waterfall: The Cost of Bugs After Launch

Dietrich Kappe, Monday, October 19, 2009 @ 1:44 pm

photo credit: bobistraveling

We have a few simple principles when it comes to software guarantees: either we have developed the software according to our rigorous testing standards or the third party code we being asked to support meets some basic criterea:

1. It has full functional specifications.
2. It has unit tests that provide better than 85% line and branch coverage.
3. It has automated functional tests that exercise 100% of the user stories.

That may seem pretty extreme, but if we're promising to fix bugs on our dime, we can't have it any other way. Doing without these basic criteria is like guaranteeing you can drive from New York to Los Angeles in 30 hours, keeping under the speed limit without a speedometer and without being told what the speed limit is. Spelling it out a little more, if you can't tell me what your application should do, how do I know if it is "broken?" If I can't run and inspect unit tests to tell if individual classes and methods are doing the right thing, how can I quickly tell if my changes have broken the system? Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Pair Programming: Lone Programmer Shoots Back

Dietrich Kappe, Wednesday, September 30, 2009 @ 2:38 pm

photo credit: Johnathan!

I got a few angry and scolding comments on my last post on pair programming. Let me address each of the issues in turn:

1. Programmers are not lazy - Rather, they are no more or less lazy than any other type of worker. Why do the peak usage times of most web sites, including Facebook and the like, coincide with business hours? You can look at the studies that reinforce this finding, but those traffic graphs speak volumes. Workers -- developers included -- that pair, spend less time on personal stuff than those that don't.
2. Nobody ever gets hit by a bus - True, but people do leave projects. Maybe the whole bus (or Pie Truck, if you prefer) is a read herring. The real issue isn't developers leaving a project. It's that you have less flexibility when one developer knows a piece of the code and the other doesn't. I can't double down on a part of the code that needs more resources, since then I'm in Mythical Man Month land and am throwing gasoline on the fire.
3. Nobody can prove that pairs are more productive - There are studies pro and con on this. I can speak from experience. I've been on a number of agile projects that did not use pair programming. We had a good history on what the velocity for each iteration was. We changed to pair programming and got anywhere from a 30% to 50% increase in velocity going forward, along with a large decrease in bug reports per iteration. That's pretty convincing.

It's easy for folks to misunderstand pair programming and to dismiss it as useless, weird or wasteful. It's one of the first things that gets ditched when the going gets tough, yet it's one of the most important, along with TDD. That's why I wanted to make as strong of a statement as possible in favor of pair programming and against singleton programming.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Getting a team over the fear of daily scrums

Michael Walkden, Tuesday, September 15, 2009 @ 1:23 pm

If my previous post about the value of agile meetings over traditional status meetings got you interested, I want to share a common pattern of behavior I often see from teams trying scrums for the first time. Hopefully you can avoid these and save yourself some time.

For new teams to Agile the statuses given in scrums are generally … well … lies. “Yep, on time. No obstacles.” I was once told by a colleague that, “You can’t hide on an Agile team.” This is true. However, this kind of exposure can be extremely uncomfortable for individuals to get used to. In traditional software teams people aren’t used to their peers asking them direct questions and paying close attention to their progress.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Wireframing with incomplete requirements

Sholom Sandalow, Thursday, September 10, 2009 @ 3:43 pm

The value of wireframing even with incomplete information

The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered.  But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements?  What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do?  Is wireframing at this juncture useful?  I say yes.  With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.

The key to a wireframe's usefulness is that it is a visual document.  Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment.  Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications.  A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation.  "Where is the Cancel button?  Oh...not in the requirements?  Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."

In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation.  Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

edge case city: requirements and testing dates for HR business logic

Jason Sendelbach, Wednesday, September 9, 2009 @ 10:42 am

edge case city: requirements and testing dates for HR business logic

We have an internal application that does staffing, time entry, and now Paid Time Off (PTO) accrual, scheduling and management. It is quite nice, as it has replaced three existing systems, and replaced a number of manual, tedious tasks. I started it last year, as our current system was very inefficient. It was a simple Ruby on Rails app that I was able to get working in a few weeks. Over time the functionality grew.

We recently added in PTO accrual and functionality to debit PTO time. In doing so in a test driven manner was great, as we could put all the edge cases. What we found was that many of the requirements were plentiful with edge cases. For instance, we get paid on the 15th or end of the month, unless that is a weekend. Then we get paid on a Friday - Except if that Friday is a holiday, then the previous Thursday - Except - if that is also a holiday.... So it is really the previous non-weekend, non-holiday on or before the 15th or end of the month. The same holds true to determine the beginning of the billing period. If the Monday is the 2nd, than for some operations the effective billing period start is Tuesday the third.... Ugh...

Our initial thoughts were filled with visions of lots of very similar tests for all contexts that do things depending on the start or end of a billing period. We didn't want to have lots of duplicate test code to test all edge cases, so we decided to extend the Date object to have a few helper methods to do the complicated logic in one place. We get the full range of the billing period start and end, and then trim off any holidays or weekends. What this did, was allow us to test the complicated logic in unit tests with a full set of complicated edge cases. We created many crazy examples of billing periods starting and ending on weekends, holidays, and holidays before and after weekends. This created a very robust set of methods to be used anywhere in the system.

We then mocked a call to each Date helper method everywhere in the system where it cared about what day it was, and weather it was the start/end of a billing period. We had only a few edge cases now: is it the true effective billing period start/end, or not. Our tests could then focus on the guts of what it actually did, regardless of the effective date.

This demonstrates how powerful unit testing is, and how mocking can really keep your tests concise. It made not only our code cleaner, but our tests cleaner. It reduced duplicate code, and increased our assurance that the code will function as designed.

That being said, it still doesn't change the fact that implementing HR logic in any language is a pain in the ass. I have worked on a couple of systems for accounting departments in the past, and their business requirements are much worse than HR. Dealing with job codes, general ledger accounts, etc can make your head spin. All I know, is that without TDD, this system would be buggy.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Agile Development and Play: Understanding the Value

Blake Smith, Tuesday, September 8, 2009 @ 3:03 pm

My Addiction

I'm addicted to TED talks. There have been many nights where I've stayed up way too late watching them. For those who are unaware, TED is a yearly conference where world leaders and thinkers gather to share their ideas and spread their passions and work. I'm someone who gets fired up listening to outher people's passions. I love hearing about what gets other people excited, what makes them tick, what makes them want to share with the world.

One of the more interesting talks I've listened to recently is by Tim Brown at the Serious Play conference of 2008. Tim talks about how the elements of play can improve creativity and productivity in our workplace and life. I found the lessons learned from this talk something that can be very directly applied to software development, and taking some of these nuggets of teaching can help me be a better thinker and worker.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Agile 2009: A reminder of why each team needs leadership

Michael Walkden, Tuesday, September 1, 2009 @ 8:44 am

Last week I presented at Agile 2009 a workshop for those new to Agile entitled: The Agile Game: An Experiential Workshop. I love this workshop because it allows those new to Agile to experience the rhythm of an agile project in action and learn first hand many of the practices in a non-threatening, non-technical, and fun way. I have used this workshop for clients a number of times and it works. The feedback from this session was overwhelmingly positive too. Comments such as, “Fun game, good to demonstrate how teams do and don’t work together” and “Very, very, practical way to get concept through” are always great to see.

Recently I had been wondering if Project Management was a questionable career choice. I have spent the last couple of years surrounded by talented individuals who seemed to be able to work fine without me. The test is always when the project manager (me) goes on vacation. Has the team fallen apart? Are they forgetting all of the practices they were doing? Is stuff getting delivered to clients? I was finding that I had a backlog of chores when I came back, but overall things were still humming along.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development