October 2006

Monthly Archive

Building “Integrity” In

Posted by on 31 Oct 2006 | Tagged as: Agile, Scrum

One of the 7 main principles in Lean Software Development is “Build Integiry In”. “Integrity” is defined as “free from flaw, defect, and decay”. Although there are many ways to build integrity into our products I wanted to suggest how Scrum and XP practices can assist in achieving this goal.

  • Free from “flaw”: In order to reduce flaw in our products we must align development with the driving business factors. We can do this by allowing business to provide a prioritized Product Backlog which is stack ranked with the highest value items at the top. We may also automate our acceptance criteria for the features pulled into a Sprint Backlog as “executable requirements” which may be regressed to make sure the intent of the implemented features continue to meet customer need. You may use a tool like StoryTestIQ to automate your acceptance tests.
  • Free from “defect”: In traditional approaches we may design and code our feature implementations and then hand off our builds to the QA team to run manual tests against the build. The amount of time from when a bug is introduced to when it is discovered, handed back to the development team, and then ultimately fixed could be weeks or months. The introduction of Test-Driven Design has decreased the amount of time to progress from introduction of a bug to fix into minutes or even seconds. Writing the tests first improves overall test coverage in our product development and enables automated regression of unit level tests.
  • Free from “decay”: Again, the prioritized Product Backlog which places the highest value items on the top to be implemented first in the product development life cycle decreases the amount of decay introduced into the product. The third leg of the Test-Driven Design mantra, “refactor”, also decreases decay in our products by continually evolving the design to meet the current needs. If our test coverage is high enough to allow modifications to the product design but still assure the functional integrity then refactoring may be performed with minimal risk. Continuous Integration is another practice that we may use to minimize decay in our products by notifying the delivery team when flaws, defects, and integration issues have been introduced. If we develop in large batches of features over extended periods of time there is technical debt which accrues and must be dealt with in stabilization phases to remove the decay from our product.

It is important to understand “integrity” and how we can build it into our products. This will allow us to deliver incrementally in short iterations, attain the benefits of emergent design, and increased value of product features for our customers.

Scrum for the Home

Posted by on 30 Oct 2006 | Tagged as: Agile, Scrum

I am sure there are going to be some people who think it is crazy but my wife and I have implemented Scrum for our home improvement needs. We do not have enough data to know if it is working yet to help with our home improvement delivery but it has already allowed us to understand our prioritizations and how much there is to do. Of course, my wife is the Product Owner and I am the ScrumMaster. Here is how we implemented it:

  1. We got together on a weekend morning and went through the house room-by-room and eventually cover the yard for what is left to do around the house. We captured these items on index cards in a very basic form such as “This is what we need to do in this room”. This took about 1 hour.
  2. After we had all of our initial index cards filled out we sat them on the living room floor and decided on a plan to get these prioritized. We decided that using a method to place a cost for each would be a good first step. We developed a high, medium, low, and no cost equivalent that seemed to work and placed the “H”, “M”, “L”, and “N” representing these costs on the top right corner of each card. This took about 15 minutes.
  3. We separated the index cards into their respective cost class so that we could prioritize each pile in a cost arena separate from the others. We prioritized each cost pile and went over our priorities with each other before moving on. This took about 30 minutes.
  4. After we had each pile separated and prioritized based on cost we decided to take the highest priority of the top index cards on the separate piles and add it to the Product Backlog as the next highest item. This took about 20 minutes.
  5. Now that we had a prioritized Product Backlog we decided to create a Sprint Backlog for the next 2 weeks. We captured about 12 of the top Product Backlog items and then placed them on the countertop and eventually into a wall mounted mail holder.

During the next two weeks we got to finishing off each of the Sprint Backlog items. We were not able to finish 3 of the Sprint Backlog items due to a change in the Product Owner’s taste of fabrics and solutions. So far it seems to work. We tear up the index card once it has been completed and add new index cards to the Product Backlog and reprioritize it every 2-3 weeks. Some of the things, from my point of view, that we must work on is getting into the cadence of a Sprint and figuring out what Product Backlog readiness means for our Product Backlog items.

My wife let me know that she felt a bit better knowing what we needed to do around the house. I felt better because we could recognize when items were getting completed. I hope that we are able to keep this up with a baby on the way soon and the continual increase in activities of our 3 year old daughter. When discussing a ScrumMaster in the CSM training course we always say a “Dead ScrumMaster is a useless ScrumMaster”. This may be our biggest risk. 😉

Agile – Short Term versus Long Term

Posted by on 16 Oct 2006 | Tagged as: Agile, Architecture, Scrum

A comment came recently on one of my posts from someone who I respect greatly, Konstantin Ignatyav:

Do not you think that Architects actually have different reading of YAGNI: You Are Gonna Need It?

Architecture is about making solid foundation that will withstand time and carry the entire building along with unanticipated enhancements and additions. But Agile seems to favor short term benefits over long term ones, while architect values long term benefits over short term gains.

In the world short term benefits can be quite disastrous in the long run. Like our 200 years old industrial revolution seems to be destroying and poisoning our habitat now.

I agree that having a vision of architecture is needed for complex projects with heavy integration into the larger enterprise architectures. Understanding the business vision and a reasonable roadmap of technology is helpful in guiding product delivery. Also, you can’t beat having good people making good decisions when developing software. When does this happen? All the time, not just at the start of the project.

I would say that it is incorrect to say Agile favors short term over long term benefits. Actually, Agile is about proving the vision continually using real world examples and then applying the best one to the situation at hand. Agile does not dictate the use of any specific tools for this cycle but there are multiple concepts which are used in Agile methods and practices:

  • Metaphor (XP)
  • Refactoring (Fowler)
  • Domain-Driven Design (Eric Evans)
  • Inspect and Adapt
  • Continuous Integration (XP)
  • Product Vision
  • etc…

All of these have potential need for the inclusion of knowledge that would usually reside with a true software architect role. In fact, Lean Software Development discusses the technology leadership role on teams and how important they are to project success. Some of us are able to view a project better from a high level business vision to a sound structure and ultimately an enterprise integrated solution. There are many ways to do this and I would not prognosticate that Scrum, XP, or any other Agile methodology is a silver bullet.

I do believe, however, that the basic values and principles of Agile can be used by people to develop processes which work best in their environment. I also believe that they must continually improve those processes to make sure they continue to be the best for the environment.

In the end, a great team and great business guidance must not be under valued. If we do not develop products which are easily deployed, maintained, and integrated effectively then there is improvement to be made. If we do not have a true product vision with high value prioritization then the ROI of our product will not be optimal.

Currently, at the team level, I expect ‘integrity’ to be built into the product from the beginning. The definition of ‘integrity’ is “free from flaw, defect, and decay”. Here are the tools which we use at SolutionsIQ to build integrity into our deliverables:

  • Free from “flaw”: Automated Acceptance Tests (Executable Requirements)
  • Free from “defect”: Test-Driven Design
  • Free from “decay”: Continuous Integration and Refactoring

As ‘integrity’ is built into the product, we can also make sure that “architecture” is visible through the acceptance criteria of PBI (product backlog items) as they are moved to the sprint backlog. You may have different definitions of “done” for each PBI and quite probably architectural constraints for it based on the organization, product, and domain.

This is such a fascinating subject to me that I would like to keep going but I think it would be best if I tried to get some sleep now. Can’t wait to talk with you more about this over a pint, Konstantin. I am sure you will enlighten me on some things and I hope that I am interesting, as well.

Happily Learning to be Conflict Minded

Posted by on 12 Oct 2006 | Tagged as: Agile

Today was an exciting day for me. Two people that I have great respect for, Esther Derby and Diana Larsen, are conducting conflict negotiation training for a group of us at SolutionsIQ. If you do not know about Esther and Diana, they have just released a great book called Agile Retrospectives: Making Good Teams Great. They both bring an incredible amount of expertise in better management skills, conflict negotiation, team improvement, and group facilitation.

Within the first 30 minutes of our class today I saw the effects of this expertise as Esther and Diana ran us through a simple exercise, “paired introductions”. In that short period of time I was able to become closer to the rest of my colleagues attending the course. We broke into pairs to gather information about the other person that we may not have known. A couple of minutes later we started going around the room with each pair introducing their partner. It seemed that everybody shared stories from outside the technology environment about each person they were introducing. This small amount of information about my colleagues is quite powerful for improving our organization as a group.

I won’t go into great detail about the other exercises of the day because I believe that you must experience these for yourself. I will provide one quote which was written on a white board by Brent Barton at work which also came up during our discussions today:

“The opposite of conflict is not harmony, it is apathy”

I do believe that everybody in that room today has already gained something from today’s discussions and activities. Luckily, we have another day with Esther and Diana. Today essentially revolved around conflict and tomorrow will be more about negotiation. What a great job I have!

A Chance to Become a CST

Posted by on 08 Oct 2006 | Tagged as: Agile, Scrum

Over the past year I have been working with some great folks at SolutionsIQ. Before taking this job it was apparent to me that the Scrum and Agile movement is where I felt most comfortable. Applying the values and principles along with the Scrum framework and XP practices I have seen an increase in success for many of my projects. I must say that working in an environment such as SolutionsIQ where Agile is the norm, and we wouldn’t have it any other way, lifted my passion for software, teams, facilitation, training, and coaching. That is why I recently applied to become a CST (Certified Scrum Trainer).

After working on Agile teams for a while I thought back to when my own career started on this path to empowered teams, removal of waste, and just-in-time development of requirements. I was brought back to a cellular corporation where I was the first developer on the team which was looking to provide a customer service portal. I started out creating prototypes to show directors and managers in the company what this portal could do. Once the project was funded I helped to pull together the initial requirements for our first release and worked with a new team to deliver it. After a couple of releases I went to PMI training and had a good instructor, although I had no idea they were so good at the time, who discussed a release planning method with customers, project managers, SME (subject matter experts), and the development team. Immediately I tried this method out for the next release of our product with great excitement. We had already delivered for 3 straight quarters to production and our customer was quite satisfied with the work we were doing. The project had sub-components which were rated first and third on the list of top initiatives for the entire division. We had done this while flying under the radar since we were their first ever externally facing web application and we had architectural control over infrastructure and design.

We started out that meeting with huge stacks of post-it notes and everybody we needed to do release planning with a recently increased team size. We had a list of functionality which we hoped to deliver this quarter and the whole group worked on breaking this functionality down into smaller units of work that could be estimated more easily. Although the iteration was for 2 months, the theme of the meeting did seem similar to what I now do today. One big difference now is that I almost never plan for more than 2 weeks. We started placing post-it notes onto the white board and discussed them amongst the team regarding design and any dependencies we might have with each piece of functionality. Approximately 12 feet of white board space was plastered with post-it notes from top to bottom. Notes were written along side the post-it notes on the white board to signal particular areas of interest in the plan. After four hours of planning in that room we ended up with a rather good understanding of what we could deliver in the next product increment.

That quarter we had great success in the delivery of a release and incorporating new people into the team. We had grown from 5 to 12 before the third release and up to around 20 people before starting the fourth release. I remember going into my manager’s office after managing the 12 people during that third release and saying “I don’t think it is good for me to manage that many people at once”. I suggested that we promote two other people on the team to lead sub-teams and my manager was very helpful in implementing this plan. I appreciated that very much. I now live by the “7 + or – 2” rule with only minor exceptions.

I began my application process to become a CST in September and found an ever increasing twist in my gut due to excitement, late nights, and even reflection about where I am in my business and personal life.  Having a great mentor like Brent Barton to help me along the way has been incredibly helpful.  After finishing my application I felt relieved but also a slite bit of trepidation about my prospects.  There are so many great ScrumMasters and Agile coaches out there who are probably in line for CST certification.  I hoped that I had the right stuff to make it on the list for this year’s Scrum Gathering interviews.

On Thursday, October 5th, I got my invitation to be interviewed at the Scrum Gathering event on November 15th.  I can’t tell you how excited I am to have a chance at becoming a CST and working with some great people in our industry.  Please wish me luck as I take the plunge.  Thanks.