Recently about Agile Development
Follow the Agile Process - it will make your life easier
One of my favorite things about Agile development is that it removes the burden of decision making from the development team. The team gets to provide facts to the decision maker (Product Owner) and then execute once a decision is made. There is no more need to hide problems or try to make up schedule time (although I'm sure that no IT professional has ever done such a thing). Developing software is what it is - unpredictable - and Agile development accounts for that through continuous planning. The best thing that a team can do is be as transparent as possible, help decision makers gather all the information that they need in order to make a decision and then sit back and wait for the next Sprint's marching orders. This allows the team to spend more time and energy on what they do really well - building good software.
Remember who owns the system
The majority of software developers out there are building a system for somebody else. Yes, there is a tremendous amount of pride and sweat equity that is built up when building any system, but we always need to keep in mind who it is for. Many times its not our system that we our building, its our customer's. Software developers get paid to develop software and thanks to Scrum, Product Owners now get paid to make decisions that directly shape the software. They get to make big decisions every month, and they should be making little decisions every day. So remember, what makes sense to you should be a starting point for implementation. Many times as developers we understand how our users think and can implement features in ways that are both elegant and intuitive - but not always. Sometimes we completely fail to grasp our customer's environment or needs and if left to our druthers would create a system that would completely miss the mark. This is the way of the past. The future (powered by Agile process) is to let our customer's be intimately involved with the software right from the beginning, and let them shape our actions so that the systems we build will be as useful as possible to their users.
Help Make Decisions
It may sound like I want to purge thought and creativity from the development team, but I really don't. The team is the Product Owner's biggest asset. The team should let the Product Owner understand the possibilities that technology can provide. We are responsible for keeping our Product Owners informed, providing suggestions, and laying out the pros and cons of various options so that they can make good decisions. There is nothing more beautiful in software development than a well oiled development team that has an intimate relationship with its Product Owner. With ideas flying all over the place, creativity and experience can come together to create game changing software that really adds value on top of the regular automation of business processes that we have learned to do so well over the past 10 - 20 years. Just remember, ultimately it is the Product Owner who is responsible for the return on investment for the system, and when it is all said and done, they have final say for implementation.
Don't fight the process
Agile requires a different way of thinking than many IT professionals are used to. Agile development asks us to give up some control over the process for building software. For many, this change can be hard to swallow, especially when we are asked to do things that we don't agree with, be it adding a particular feature or changing the layout of the UI. In these cases, feel free to voice your opposition, but remember your role. System design and implementation is your thing. Deciding what to do and when is up to your Product Owner. You will likely have very good input on these matters, and if you voice your opinion respectfully (not forcefully) in time your Product Owner will come to trust and depend on your sage advice. Allow the iterative nature of the Agile process to work to your advantage. If your Product Owner fails to follow your advice and makes a bad decision, it will be brought to light rather quickly. Its OK to cut them some slack. One thing that as developers we love about Agile is that it tells us that we don't always need to have all of the answers. I think its reasonable that we don't expect our Product Owners to always have all of the right answers either.
Let me sum up
Agile development isn't easy. Bridging the gap between the business side of an organization and the IT side of an organization is extremely hard. As software developers, by giving up a little bit of control and not giving in to our egos always telling us we have the right answer, it will be easier to benefit from all of the wonderful joys that Agile Development has to offer.
- "Programming is a social exercise" - I thought this was a really good point. It was mentioned in the context of pair-programming, but I think it has far-reaching implications. Software development is more than just running through a bunch of formulas and crunching out an answer. Interaction within the team and with domain experts is crucial, to not only build the software right, but build the right software.
- "A refactoring is something that takes a few seconds, or a few minutes at most" - I was really impressed with the importance of automated refactorings in his discussions. I think most of the time that I spend "refactoring" is in small, manual edits, whereas most of the time that he spends is in using automated refactoring to "chunk" his edits. I definitely need to learn these keystrokes and refactorings better. Maybe I should start a "Refactoring Driven Development" movement...
- "Don't put refactoring on the schedule; do it all the time" - Simple, but effective. My tendency is to want to spend all my time refactoring, but this curbs that, because it forces me to refactor while I'm delivering user stories.
- "There are 3 essential design skills: nose, vision, and plan" - A nose for recognizing design smells, a vision for seeing a good design for your codebase, and an ability to come up with a plan to get from point A to point B.
- "Testing trumps good design" - This bothered me at first, but I think it's a really good point. The idea here is not to say that design is not important. But, rather, if you are forced to choose between between a "bad" design that allows better test coverage (e.g., less encapsulation), and "good" design which is hard to test, choose testability. The reason here is that the biggest roadblock to changing your codebase is not bad design, but FEAR of breaking something. If you know you will know when you've broken something, then you can retrofit a better design later.
- "There is self-worth tied up in "finishing" something" - He also drew a distinction between having something working (which some developers will call "finishing" it), and finishing it - making it not only work, but be thoroughly tested, maintainable, etc.
- Presentation layer - he talked about having the thinnest possible UI layer, which talks to a presentation layer to find out everything about how it should render. Then test the UI and business logic completely separately
- "You aren't doing agile development unless you are tracking your velocity and remaining story points in terms of passing, automated acceptance tests" - I balked at this at first, feeling like it was too easy to use this as a performance to beat the team over the head with. After I thought about it, though, it's really about the definition of done. We are done if all the features we said would be working are working. And how can we know this? Only by testing them. Continuously. Which means it should be automated.
- Acceptance tests don't need to be end-to-end, and, in fact, shouldn't be. This is another one that made me hesitate. After all, how do you know the feature is really working unless you go all the way from the UI to the database and back? Well, in short, because you're the developer. There's more value in being able to test features fast, constantly, than in being able to truly test them all the way from one end to the other. Mock/stub out what you need to to make that happen.
- FitNesse is cool. This is the second time I've played around with that tool, and the second time I've been impressed with its power and simplicity. I definitely need to play around with it some more.
I love tracking user stories in SharePoint. It's free (assuming you have access to a Windows Server 2003 or 2008 machine with WSS turned on) and is extremely flexible. Adding new custom columns is easy. Adding custom views is easy. Bulk editing is amazingly simple and powerful (assuming you're willing to use IE). And building a custom home page "portal" with all the states of your team's workflow (e.g. unassigned, stories I'm working on, my resolved stories, to peer test, etc) is easy and is intuitive to use.
This 13 minute screencast shows you how to create a user stories list in SharePoint and build burn up and burn down charts off of the data using Microsoft Excel. It includes the custom fields you'll need in SharePoint, the formula's you'll have to create in Excel, and shows tips along the way like how to simplify refreshing your reports when data changes.
Once you've watched the screencast if you want to implement this yourself here is the information you'll need:
Custom SharePoint Columns
- Iteration (Choice column e.g. Iteration00, Iteration01, zBacklog)
- Released (Date - the date the iteration was closed out)
- Points (Number)
- Created Date (for demo only, you should be able to use "Created" on your project)
Calculated Columns in Excel
- Total Points to Date
- The total points on a specific date including backlog, current iteration and all completed stories
- =SUMIF([Created Date],CONCATENATE("<=",Table_owssvr_1[[#This Row],[Released]]),[Points])
- Completed To Date
- Total points for stories released prior to current story's release date
- =SUMIF([Released],CONCATENATE("<=",Table_owssvr_1[[#This Row],[Released]]),[Points])
- Backlog
- What remains to be completed at a point in time (e.g. don't include user stories added to the backlog in iteration 4 if this is for a task in iteration 03)
- =Table_owssvr_1[[#This Row],[Total Points to Date]]-Table_owssvr_1[[#This Row],[Completed to Date]]
Burndown Pivot Table Values
- Row: Released
- Filter: Released After [Some Date]
- Values: Max(Backlog)
Burnup Pivot Table Values
- Row: Released
- Filter: Released After
- Values
- Max(Total Points to Date)
- Max(Completed To Date)
Summary
I hope you found the presentation useful and if you are currently using SharePoint for tracking user stories please comment on your experiences.
As a software developer I never thought I'd be saying this (I suppose eight years of working for the company that invented this technique might bias me), but you can not underestimate the value of business process modeling when starting a new project. This is especially true if it's a small project and you don't have the benefit of a dedicated requirements analyst.
As a consultant (or as a person who is learning someone else's business) your job is to understand your customers existing business better than they do themselves. And you need to be on the same page with others regarding how you are going to change their day to day functions. And that's what business process modeling is for.
You may ignore this document after the first week on the project, in fact I would encourage you to. But even if you throw it away immediately after creating it, the process of developing the document will still:
- Flush out important questions
- Show your customer you understand their world
- Help document the project to other developers
- Facilitate communication (especially with the people who pay the bills)
- Generate user stories (requirements)
- Identify the entities that can feed into an Entity Relationship Diagram (or database I suppose)
- Aid making good choices for the decisions it be hard to undo later (like whether to manually code workflows or use Windows Workflow Foundation)
- More clearly identify pain points and areas where your software can help end users; and
- Identify metrics that can help determine project success from an ROI and product owner's perspective
Convinced this is a tool you need in your toolbelt yet? As long as the answer isn't "I only write code leave me alone" then check out this quick how-to:
Start with the AS-IS diagram
As soon as possible on a new project you should plan to interview your future end users. This shouldn't be an unstructured Q&A session. You should start with a rough draft of what you think their business process is and ask questions that identify the places where you were wrong.
In order to start the diagram you need to identify both the end users and existing systems and put those in "swimlanes" down the left side of a diagram. Swimlanes are important because they help you be explicit about who is performing what activities. Then flush out activities in the happy path in appropriate swimlanes like so:
As soon as you talk to end users (like the clerk in the example above) you will discover unhappy paths. What if the warehouse is out of a product? What if the payment was declined? What happens if a customer needs to return something?
Obviously you document these using standard activity diagram notation:
Identifying Pain Points/Opportunities
The interesting part about unhappy paths is how often they occur, how they affect the customers of your customer, and ultimately how they affect your customer's bottom line. For instance, how often is payment declined in the example above? Fairly frequently? Can you get an actual percentage? If it turns out it's because the original application failed to validate credit cards, then a small amount of programming effort can provide a large benefit to length of time until order fulfillment. Sometimes you can make the process more efficient without writing a line of code.
And at the end of your project if you can show that you've decreased the average length of time it takes to go through the process, ideally by showing less time was spent in unhappy paths, you will likely have made yourself one happy customer. This can be especially effective if your new system can show statistics (like percent of orders that are declined) and compare those to the old process.
Developing the TO-BE diagram
AS-IS process diagrams are completely useless unless you can effectively describe what the process will look like after you implement your new system. The process of developing these documents is pretty similar to the AS-IS diagram except of course you're trying to fix the pain points.
One technique I like for generating a backlog of user stories (tasks) is to put unique numbers with each step in the TO-BE process, then ensure there is at least one user story per step in the process. You may be surprised at how easily activities in your new project's swimlane map to user stories.
Summary
I'm a fan of writing code as soon as possible on a project, but if you fail to understand an end user's business process you may be writing the wrong code. Business process modeling can ensure you're writing the right code to solve the most important problems first. And that may be the difference between project success and project failure.
