The Westboro Systems Blog
Smaller User Stories?
Alice was talking with me the other day about User Stories. She was telling me how we “must really get to smaller stories because our testers on the team are overloaded near the end of the Sprint”. Alice then goes on to remind me that “The team has plenty of...
We are the Borg
Star Trek The Next Generation brought us the Borg, an alien race that function as drones in a Collective; i.e.: Borg are interchangeable units in their organization known as the Collective. Organizations have much the same concept by referring to people as resources. Treating each person as a resource has...
Every little thing
In 2010, Dave Brailsford, Great Britain’s Performance Director for British Cycling, set a goal to win the Tour de France in 5 years. Quite the ambitious goal since no British cyclist had ever won the Tour. In 2012 Bradley Wiggins became the first British cyclist to win the Tour de...
What problem are you trying to solve?
“We want agile.” Have you started a conversation that way? The thing is, you likely need to back up a couple of steps and consider what the problem is that you are trying to solve. There is a good chance that if you try to apply agile to an unstated...
There’s a new look around here
The Westboro Systems site has been redesigned! There were a couple of goals for the new design, including: To create simple, straightforward, and to the point messaging that allows you to find information easily. Provide a clean and clutter-free look with most of the content easy to find and view...
Product Management
The only constant in life is change. Requirements change. In an Agile environment, requirements change a lot! This may be due to changes in the business, change due to new market opportunities, or simply change that occurs as you discover requirements during the development process. If that’s the case, though,...
Business Agility
Are these goals important for your organization? Faster time to market Higher quality Exceeding your customer’s expectations Lower project risks Ability to quickly respond to changing requirements Business Agility is the ability to quickly and cost effectively respond to change. With Business Agility you can cut through the complexity in...
Yesterday’s Weather
It is said that if you forecast the weather for the next day based on today’s weather, you will be correct 70% of the time. This concept is used to determine how much work for which the developers can sign up in any given iteration. The total number of points...
Watch for Technical Debt
Any code base will contain build up Technical Debt over time. This is even more true for code that does not have any automated tests. You can easily see the symptoms of Technical Debt: Velocity begins to erode – the team spends as much or more time fixing defects as...
User Story Examples
Quite often it’s difficult to get started writing User Stories for the first time. Here are some sample User Stories that may provide some guidance. In general, though, there are a few guidelines you can follow to make a good story: Short Title with Active Verb – the title of...
User Story Estimation
Agile approaches prefer to use a simple estimation technique called Relative Estimation. Consider this stack of books: If you estimated the number of pages in each book, you would have some very precise numbers. You would also most likely be quite incorrect! What if you took one book – for...
User Stories
A User Story is a short description of the behavior of the system from the point of view of the Product Owner. They are in the format of about three sentences of text written in the Customer’s terminology without technical jargon. In simplistic terms, user stories are the response to,...
Use Retrospectives to Improve
Agile teams use Retrospectives at two levels – at the end of each Iteration, and at the end of each Release. In both cases, the goal is to identify not only what didn’t work well for the team, but to acknowledge what did work well. It’s equally important to learn...
The Spike – Experiments to Improve Learning
There are situations in which the developers simply don’t know enough about a Story to be able to provide an estimate. In that case, they would perform what’s known as a Spike. The Spike is simply a quick, throwaway proof of concept to allow the developers to gain an insight...
Agile Planning Process
Plans are worthless, planning is essential. — Gen. Dwight D. Eisenhower One of the myths about Agile is that it is disorganized coding with no documentation or regard to planning. Nothing could be further from the truth. In fact, planning is one of the more important aspects of Agile, and...
Test-Driven Development (TDD)
Effective Agile teams use a technique called Test-Driven Development (TDD), in which the unit tests are written before the code. Then, just enough production code is written to allow the test to compile, but not pass. The unit test is executed to ensure that it really does fail. If it...
Sustainable Pace
Tired team members make more mistakes. Airline pilots, truck drivers and other occupations that require sharp concentration mandate the maximum number of hours that can be worked. That doesn’t apply to the software industry, and the overall quality of software reflects that fact. Agile advocates only working overtime if it...
Standup Meeting
Each day, the team gathers for a very short meeting to discuss the current situation on the project. For this meeting, everyone stands in order to avoid long detailed discussions. This is the Standup Meeting, and is used to allow everyone to keep their finger on the pulse of the...
Simple Design
A program built using an Agile process should be the simplest program that meets the current requirements. There is not much building for the future. Instead, the focus is on providing business value. Of course it is necessary to ensure that a good design is used, and in Agile this...
Retrospectives – Improving Your Process
Agile teams strive for continuous improvement. Just as Refactoring is used to improve the design of the code, Retrospectives are used to improve how the team works. Traditionally, retrospectives were held at the end of a project and were commonly known as post-mortems. Other than the connotation that the project...
Release Planning
The development team needs to release incremental versions of the system to the customers as often as possible. Release Planning is used to discover small units of functionality that make good business sense and can be released into the customer’s environment as soon as is possible, and makes sense to...
Refactoring
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each...
Project Velocity
The use of the term “Velocity” is very deliberate in Agile. Velocity is defined as the rate of change of position over time along a straight line. It is a vector quantity, adding the dimension of direction to the scalar value of speed. This applies to a software project in...
On-site Product Owner
Lack of user involvement traditionally has been the No. 1 reason for project failure. Conversely, it has been the leading contributor to project success. Even when delivered on time and on budget, a project can fail if it doesn’t meet user needs or expectations. — Software Magazine, Feb. 2001, Collaborating...
Managing Scope Creep
Many people have said that embracing change in Agile leads to scope creep and churning, and in the end nothing gets delivered. Consider this analogy: You’re renovating a bathroom, and you planned to change the sink & vanity, reuse your existing tub & shower, and put ceramic tile on the...
Know Your Done State
Knowing when a Story or Feature is ready to be put into production, the Done State, is critical. It doesn’t matter if the developers believe that they’re done, or even if QA says a feature is done, if the the business people for whom the feature is being built don’t...
Iteration Planning
Iterative Development is a key element to adding agility to the development process. The development schedule for a release should be divided into iterations of about 1-3 weeks in length. This length is kept constant, despite pressures to increase length in order to fit “one more feature” in. The result...
Frequent, Small Releases
The developers put a simple system into production early, and update it frequently on a very short cycle. This makes the software ‘visible’ to the Product Owner and Stakeholders, and is a much better indicator of concrete progress that updating a project plan. It also gived the Product Owner the...
Continuous Integration
Continuous Integration is a practice in which the team checks in and builds the software system as often as possible. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less...
Collective Ownership
All of the system artifacts belong to the entire team. This allows the team to continuously move forward, avoiding bottlenecks caused by islands of knowledge in the team. This improves flow and thus productivity, and reduces the risk that work will be disrupted by staff turnover. Generalizing Specialists In order...
Coding Standard
For a team to effectively share ownership of all the code, all the developers need to write the code in the same way, with rules that ensure the code communicates clearly. The specifics of the coding standard aren’t all that important, just that all team members follow the same standard....
Code Oversight
A relatively important practice in Agile is the use of multiple pairs of eyeballs to help ensure that the code that is being delivered is of the highest quality possible. Quality in the context means low defects, good design, adherence to local standards, and suitability to the task at hand....
Automated Testing Enables Agility
Automating tests at the unit and acceptance level are the “grease that helps the wheel turn” on Agile teams. Does automated testing take extra time? When you’re first starting, yes. However, you must consider automated testing an investment that will bring significant returns in the medium and long term, at...