Author Archive
Planning
Posted by: | CommentsI really appreciate that amount of time we spend in planning for a sprint. For a two week sprint we spend one day in planning. I know in the past that teams that I worked with thought this to be a “waste” of time. They wanted to start programming. My new team is developing a habit of doing sprint planning which will be very beneficial.
We are tasking our user stories with a high level of detail. Most tasks are not more then 4 hours in length. This is helping the team to better understand what needs to be done. During the planning session yesterday we moved some user stories to the backlog because the product owner was not clear on the requirements. In the past this would have lead to development churn or wasted time during the sprint. It is much better to discover this at the beginning of a sprint through sprint planning.
Planning for the two week sprint also helps the team to understand inter-dependencies. Having smaller sprints gives the freedom to move stories to the backlog.
Starting all over
Posted by: | CommentsWe are starting all over again. This is a time of new beginnings. I have joined a new team and this time I am not the Scrummaster. This is a switch for me. I believe this will be a good role for the next 6 months. It will help me understand the technical challenges being faced by team members.
This team I am on is very new. I reminds me of 3 years ago when I first joined my current employer. Here is how they are new:
- New to the company. Most have only worked for the company 3 or less months.
- New to the process. Most have not worked with agile before.
- New to each other. Most did not know each other 3 months ago.
So this team must go through the forming, storming, norming and performing stages. It seems that every time I work with a new team that they think they are different and do not have to go through these phases. Now matter what they think they will progress through each of these stages.
Another observation is that the team is not good at planning for a two week sprint. They are overly optimistic and have committed to more work then they can get done. I know they are new and want to prove themselves but they do set themselves up for failure.
When it all comes together
Posted by: | CommentsWe all know the different phases of team development: forming, storming, norming and performing. In this last sprint I saw the team go from norming to performing.
In my 6 years of Agile practice this last sprint was as close as I seen a team do all of the best practices of a Scrum team.
It started with an excellent planning session at the beginning of the sprint. We actually took 3 hours to do our sprint planning. The product owner did an excellent job of clarifying the requirements and the team came up with a very comprehensive set of tasks for the sprint. Our testing engineers participated and helped us understand the issues we would face in testing our code.
The sprint started on a Wednesday and by the next Monday we were completing the first of the user stories and QA was doing their final testing. The user experience designer (UED) was constantly updating the high fidelity wireframes to reflect the necessary changes in the user interface. We had a hour of the product owner’s time each day to clarify ambiguities in the requirements. Through the rest of the sprint we were finishing new user stories and they were accepted by QA, UED and the product owner.
Our velocity actually increased during this sprint. We brought forward two user stories from the next iteration into the current iteration.
Team members stated that the last days of the sprint did not seem like a mad rush to finish the user stories. We only had two user stories out of 16 that needed to be finalized and tested in the last two days of the sprint.
The sprint demo was flawless. It was the climax the hard work and excellent team work of a performing team.
Working software in the first sprint
Posted by: | CommentsWe just finished our first sprint for a new feature. I have noticed that the initial sprint many times is very difficult because you do not have any code with which to start and the new feature is just written on paper.
A goal of Agile is that every sprint delivers working software. I know in the past that has been a real issue in the early sprints. How do you develop working software in three weeks?
The key to developing working software is to do figure out what is the scaffolding that needs to be in place to create a minimum working system. It is critical to understand what are the essential feature that are required for a working system. How much of the “happy path” can you “hard code” to create working software?
Defining what is essential is not easy. You have to take a look at your high level design and determine what is a working system that will be a true initial representation of the final product. What we build in this initial sprint will create the foundation for subsequent sprints.
I have found out that it is critical for the technical development lead to take leadership in this area. He or she, with the help of the team, can create the vision for this first sprint. Once this vision is established the team knows exactly what they are working toward. They can see how all of the pieces fit together to meet the goal of working software.
In the case of this sprint we had to create a vision that was not really a user story but was a overriding goal that we had on the white board in our team room. We could always point back to the vision for the sprint and see how we were doing. All team members agreed to the vision so this became a great unifying theme.
As the result of this vision for the sprint we came up with great sprint demo of a working feature. It provided the product owner and stake holders clear understanding of the functionality and how the feature will evolve in the future sprints.
Pre-Planning or Sprint 0
Posted by: | CommentsAdopting Agile in an large organization presents many challenges. This is especially true when a project contains multiple teams that have to create an unified product. One must be able to parse a project so that individual teams can work on a sub-system and have it integrate smoothly with the product.
In the organization I work with we have added a new step in the process. I will call this our Sprint 0 iteration. This iteration is used to create the initial backlog for the release. The participants in the meeting involved the team working doing the programming, the lead architect, best practices team, product owner, service representatives, user interface designs, quality assurance and management.
The goals are as follows:
- Understand any major architectural issues
- Identify where the software has to interface with external subsystems
- Define how to communicate with external systems
- Define the overall system constraints
- Have the product owner clarify the requirements
- Define the initial user stories.
- Size the user stories
Even though I believe very much in team making its own design choices, having the experts available to assist the team is very beneficial. This allows us to better understand what we are developing. This has given us a level of confidence in our estimations for the upcoming sprints.
This does not minify the role of the product owner during a sprint. Their involvement is very critical to the team maintaining their velocity during a sprint. The product owner has to constantly reviewing the working software to make sure we are on track with the expectations.
Iteration Reflections
Posted by: | CommentsWe finished an additional development iteration. This iteration was unusual in that we were adding features to a product that was to be released September 27th but the schedule was slipped because of another project dependency. So this iteration involved last minute planning and development. This in itself caused us to take on user stories where we as a team had no background. So this moved the team to the next level of performance. Here is what we did and the outcomes.
- Responded to a high priority user story
The business had a user story they wanted done. There are five scrum teams and most did not have the bandwidth to take on the story. We as team made a commitment to the business to do this story. - The teams quickly estimated user story sizes
We are learning how to trust our initial sizing without doing extensive designing. We had a very short time to estimate so we had to finish them quickly and abide by the estimate. - The user story was used correctly
We had the user story narrative along with at most three lines of acceptance criteria. The user story was actually used as a talking point with the product owner. The product owner refined the requirements during the sprint by reviewing work in progress. The daily demos were an excellent catalyst in firming up the requirements. - The product owner was available
To do this user story we got a commitment from the product owner to block out 90 minutes of their day exclusively for the team. The product owner is remote so we could not just go over to her desk. This worked well because we had her dedicated time every day. - The team demo incomplete stories daily to product owner
Because our product owner was available for 90 minutes a day we used this time to do daily demos and to get feedback. There always was a reluctance with the developers to demonstrate incomplete user stories. The developers had to do this because the product owner did not understand what they needed in the final product. The requirements became clearer as the product owner responded to features that were partially complete.
It was really a pleasure to see the team perform so well. In the sprint we created the user stories, designed, built and tested the feature. We made our commitment to the business in finishing the feature in one sprint.
We as a team are really excited about what we can do in the future base on our performance in this sprint.
Simple, Simple, Simple
Posted by: | CommentsIn every endeavor that we participate there are fundamental principles that need to be understood and applied. So many times we create overly complex solutions because we have broken one of the fundamental principles.
I just came from a discussion I have bi-weekly with other Agile coaches. We were discussing the role of the product owner on an Agile team. I had to be reminded again what are the core roles of a product owner. (These come Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition p. 171 Lyssa Adkins)
- Business value driver
- Daily decision maker
- Vision keeper
- Heat shield
- The one ultimately responsible
When working with the product owner we can constantly coach them according to these fundamental principles. If we go back to these and constantly “grade” their performance we will go along way in improving their role in the process.
Quality and the process
Posted by: | CommentsQuality of software or any product that we sell and provide a customer seems to be talked about but not effectively addressed in most software processes. In the process of reducing the size of my technical library I have been looking at some of my “old” books. It is interesting to see how many of these books are referenced in new books that are published.
The book “Improving Software Quality: An Insider’s Guide to TQM” by Lowell Arthur (1993) is one I was just perusing. In the preface he has a section on eliminating the testing group. Wow, this is a book on Total Quality Management and they made a bold statement such as this. Tell me how many companies have eliminated their testing groups to improve quality?
Here are some other quotes from the preface:
Create a constancy of purpose toward quality and continuous improvement
This is a underlying principle in Agile development. The whole team is involved in process improvement through constant inspection.
Institute leadership instead of management by numbers
That is the goal of self-organizing teams. Leadership is distributed among the team members in that they agree to common goals for quality and hold each other accountable. Just having a list of defects and managing this list is not a sign of a quality organization.
Drive out fear so that everyone may work effectively.
Time and time again I hear the complaint that a person is evaluated by the number of defects that are found in their code. This creates an environment where people want to cover up any problems they discover. I just recently had to defend the number of defects that were recorded against our team during a clean up sprint (these were actually new requirements). I want any defect to be recorded so we do not have them reach the customer. Removing the fear of recording defects goes a long way to creating an quality product.
Break down barriers between departments and work groups
Simply stated, have cross function teams. If everyone is on the same team you have no barriers.
Eliminate slogans, work quotas and management by numbers. Substitute leadership.
What would our managers do? I guess I am being a little sarcastic. But so many activities our managers do do not enhance quality.
Remove barriers that rob workers (management, professional and craft) of pride of workmanship.
Nothing encourages a team more then a job well done that exceeds customer expectations. We want to be proud of our work.
Nothing new is under sun as wise King Solomon said. Agile development provided solutions that provide for a quality product.
Rhythm and development (Part 2)
Posted by: | CommentsI last addressed how important rhythm is to software development. But what disrupts rhythm for a team?
- Crises scheduling
A crises arises and management decides that we have to address the crises. The team has planned iterations to meet a release schedule but now this schedule is preempted. This is like asking a painter to paint a different section of a house. He has to climb down the ladder, move the ladder and climb back up. The team will have to “climb down” current project and “climb up” the new project. - Team member shuffle
Performing teams have worked out their rhythm. They know want needs to be done during an iteration. They have built trust among themselves. When a new member is added or a member removed the team rhythm is destroyed. You have to recreate the trust that helped the team perform so well. - Requirements churn in a iteration
This happens when a product owner changes the requirements for a user story during an iteration. Work already completed has to be redone. Productivity is decreased because the goals of the sprint has changed.
These are some rhythm disruptions I have observed.
Rhythm and development (Part 1)
Posted by: | CommentsWe see rhythm all around us. Day and night, awake and asleep, 7 day week, the years, the seasons, and music. Rhythm is very much a part of our lives. When the rhythm of our lives is disrupted we may become anxious or our productivity decreases. I know from personal experience if I do not get my Sunday afternoon nap my workweek is affect adversely.
Rhythm is important to any development process… Rhythm can battle complexity, keep competition off-balance, maintain sanity and predictability for architecture and development teams.
Software Architecture Organizational Principles and Patterns, Dikel, Kane and Wilson Page 73
This is one of the underlying principles of Agile that we are aware of but have a tendency to assume. As you will notice from the above quote this is a principle that is recognized as a good practice for architecture.
What are the benefits of a team getting into a rhythm?
- Predictability
Our customers and stake holders know they will see working software on a set schedule. When the stake holders see the team meeting their commitments with scheduled demonstrations a sense of order comes over the project. - Managing requirements
We can manage many requirement “crises” by instructing the stake holder we will consider the new requirements in the next iteration where the product owner can prioritize the requirement. All new requirements are reviewed so no one feels they are being ignored. - Periodic inspection
Continuous inspection is the mainstay of Agile development. Knowing that we have our customers reviewing our work will make us comfortable in that we are creating software the meets the needs of the customer. - Demonstrations of working products
We have working products that are tested and ready of the customer to use at the end of every iteration. This help guarantee quality. We are “putting the stake in the ground” which helps us to make critical design choices expediently. We cannot get into analysis paralysis if we know we have to deliver working products.
I am sure there are many more benefits of being in a rhythm. But as noted above rhythm is very important in Agile development.