Posted on Fri, May 24, 2013
by David Wylie
Our development teams have an insatiable need for work to do. It is very common for them to deplete the Product Backlog of items that are ready to be taken into a sprint. It is also common that the Product Owner (PO) and stakeholders have lots of partially defined work in the backlog. This caused frustration because the team can’t bring in work, yet there is plenty to do.
To help with this, our teams work with the PO to agree on what defines a “ready” state of a backlog item. This will vary by project, but below are some elements to seed the discussion:
- Story defined and written
- Story traceable to source document (where appropriate)
- Acceptance criteria defined
- Dependencies identified
- Size estimated by delivery team
- User experience included (where appropriate)
- Performance criteria identified (where appropriate)
- Person who will accept the user story is identified
- Team has a good idea about how to demo the user story
Some other really smart Agile thinkers have been talking about this for a while:
We suggest that the Definition of Ready be published to the PO and all stakeholders we can identify. It also highlights the importance of the ScrumMaster’s opportunity to support the team by working with the PO to ensure there is at least a sprint’s worth of data ready to go. Along with a team Working Agreement and Definition of Done, consider adding the Definition of Ready to your Scrum team's toolset.
Posted on Fri, May 03, 2013
by David Wylie
Some people that are new to Scrum believe that the product owner has to be kept at arm’s length. Originally, Scrum books taught that the PO and the development team were separate. I’ve even heard people state that the PO is a chicken, and not as committed as the pigs on the development team. However, according to the latest Scrum Guide, the Scrum team includes the development team, ScrumMaster, and product owner.
Is the product owner part of the team or isolated? Agile principles say that the team should work with business people daily, and the best way to convey information is face-to-face; we also teach that teams ideally are colocated. So in an ideal state, the PO does colocate with the team -- if not, he or she still needs to be available to the team on a daily basis, either in person or via other communication methods.
It always depends on the people involved, but many teams are including the PO in sprint retrospectives. If there is a lack of trust between the development team and the PO, then the ScrumMaster has work to do. Everyone should be working together to deliver value, and the best product owners are on the team.
Posted on Wed, Jan 09, 2013
by Ambika Patil
SolutionsIQ was recently present at the Agile Scrum International Summit in Bangalore. Witnessing the upcoming advances in the field of Agile and adding flavor to the event were our very own speakers.
The event, conducted by Bacancy Technology, boasted a huge turnout and saw in attendance enthusiasts from around the globe. Speakers from SolutionsIQ covered a wide range of topics at the event. Vibhu Srinivasan and Joe Justice spoke about the pros and cons of the role of team manager, and Joe explained how the WIKISPEED project, a self-organizing team, was able to develop a 100mpg car in three months and win international acclaim. Throughout the day, SolutionsIQ made an impact through various presentations, discussing topics like retrospectives and being a good ScrumMaster.
The highlight of the day was the morning session, in which Vibhu and Joe engaged the participants in activities where they had to come up with reasons why a manager is needed or not needed in a team. The participants came up with many suggestions for being a better manager, including:
- Avoiding micromanagement
- Avoiding many meetings
- Empowering the teams after empowering oneself
- Team rewards instead of individual rewards
To enliven the session, the audience was given a surprise questionnaire where they had to guess the contents of a ScrumMaster’s tool kit on a piece of paper and drop it in a bowl. During a tea break, a raffle was conducted and the two best answers were rewarded with a ScrumMaster’s tool kit from SolutionsIQ.
Naveen Nanjundappa’s session was “Scrum Horoscope”. He entered dramatically like a yogi; the audience was keen on getting their Scrum team horoscopes read and predicting the impending problems in their team.
Jayaprakash Puttaswamy’s session was “Raju bangaya ScrumMaster”, which detailed the journey of a ScrumMaster and the impediments he or she must overcome. JP engaged the audience in activities that taught them how not to be a "dead" ScrumMaster.
The conference was a huge success and was a perfect way to end a year filled with Agile learning throughout India.
Posted on Thu, Dec 06, 2012
by Harmony Jones
Our office move is just around the corner, on Friday, December 14. We used Agile methods as part of our planning process to help employees determine where they’d like to sit. We didn’t want to direct people using a top-down approach -- we wanted employees to have a choice and feel engaged in the process.
Most said they didn’t care where they sat as long as they were with their team, but we recognized that their minds may change after time in the new space. In some cases, people didn’t want to bother anyone with their personal preferences; others trusted the process and wanted to take a wait-and-see approach. However, our goal was to not just have the ability for teams to sit together, but to make sure every voice was heard no matter how reserved.
We thought that getting all of our consultants to meet on this subject would be painful, mostly because many of them are working at client sites. We needed to determine a way to get them involved so they felt they had voices in the process. Here’s what we did:
- Representatives from each team collaborated with members and gathered their personal preferences.
- The reps then had an initial meeting to identify where teams would sit as undisrupted groups.
- After the teams selected their locations, they met among themselves to determine final seating arrangements.
- They plotted their locations on the large office layout (big visible chart), made cutouts of scaled desks, and placed them on the layout.
Once these were in place, team members met to look at the options and decide exactly where each member would sit. Here are some examples of how teams determined member locations:
- One team did a lottery.
- Others had group discussions to hash things out.
- One of our largest teams is distributed, with some members spending less than 50% of their time in the office. They decided that it would be a good idea to have some “hoteling” desks -- designated work stations for distributed members to use when they are here. They dispersed these desks among other team locations so that visitors would be able to pair with someone who is in the office more than they are.
- Each group in the organization had different ideas about desk orientation. Some opted for U-shaped groups, while others wanted desks facing each other, etc.
As with any move, there are unknowns that will need to be addressed:
- How noisy will it be?
- How much personal space is available?
- Are there enough electric outlets and are they placed properly?
We’ll know the answers to these questions once we’re in the new space. Then we’ll iterate and solve any problems using the same Agile processes, so everyone feels engaged and has voice in the process and decision-making.
Posted on Thu, Nov 08, 2012
by Jayaprakash Puttaswamy
Any complex work requires a lot of inspect and adapt actions throughout. This is especially true when we are working on a complex project with multiple people involved, various changing requirements, and other real-world constraints.
When it comes to the Agile way of working (using any of the Agile practices like Scrum, XP, etc.), the team's ability to inspect and adapt has a major impact on a project’s success or failure. In fact, some surveys show that ineffective use of retrospective is the number one reason Agile adoptions fail.
If I meditate deeply and reflect on my own experiments with Agile in both software and non-software projects, I see that having constant “inspect and adapt” sessions with my teams was the driving force that kept us going.
Different projects require different ways and frequency of retrospection. Here are a few of them I've used:
- Retrospective for Scrum teams, every sprint for new product development
- Introspection at the strategy level when working on a long-term initiative
- Cross-team retrospectives at the release level for product development in a scaled environment
- Daily or alternate day inspect and adapt sessions for short engagements (1 to 2 weeks)
- Kaizen with WIP limits and waste management for maintenance projects
It is also important to keep these aspects of retrospectives in mind:
- Retrospective sessions need to have a good mix of healthy debates and fun, otherwise it becomes mundane and boring after a few sessions.
- Different retrospective techniques should be tried to keep the participation level high.
- One should create a congenial environment to let people share the truth or real feelings in retrospective sessions.
- Retrospective sessions should always end with sensible and feasible action items which can be implemented in a couple of iterations.
Irrespective of the nature or duration of a project, constant introspection about goals, priorities, and execution strategies is crucial for risk mitigation and dealing with changes using the Agile approach. In fact, “inspect and adapt” is the key practice out of all the Agile practices from a sustenance point of view. Isn’t it?
Posted on Wed, Oct 31, 2012
by Harmony Jones
SolutionsIQ's Redmond, WA headquarters will move to a new office in December! This offers a unique opportunity to redefine what we consider essential working spaces. It's a brand new building which is unfinished inside. We asked our employees to tell us what they consider the most important attributes of an Agile workspace via a voting board we posted in the center of our current office:
The most popular requests were natural light, persistent personal space, an exercise facility like the one we have now, and fast wireless connectivity. We have made it a priority to ensure that these four features are implemented in the new space, in additional to making the space as open and collaborative as possible.
- No more tall cubes! There will be rolling desks for developers and consultants in the yellow area, and stationary desks with lower walls and tempered glass partitions for our operations departments (HR, Finance, Sales, and Marketing), located in the green areas. The goal is to allow as much natural light in as possible and not block anyone’s view of the outside world.
- Corner windows are reserved for community lounge areas (orange).
- A café area will be installed between the two largest work areas (large orange area). There are no walls separating this space from the rest of the building. Shared light and work space will be available.
- We have asked our builders to install a fitness room with padded flooring. We will bring all of our current fitness equipment with us and continue to provide a workout room for our employees.
- Since we will have limited wired connections, we'll be relying mainly on a wireless system for our workstations -- we will have an upgraded wireless network to support the needs of our employees.
Watch this space for more updates as we move along with our big construction project!
Posted on Thu, Sep 27, 2012
by Joe Justice
During the daily standup meeting, the ScrumMaster records the blocking issues team members raise by writing them down as tasks on their impediment backlog (or placing them as impediments on the team backlog). That helps keep the standup on track by avoiding discussing the block until after standup is completed, and then letting team members opt in to that conversation.
What are the ScrumMaster's resources for bulldozing those road blocks so they can report back to the team during their standup the next day?
The ScrumMaster makes the waste generated by the block visible. If it is in their power to unblock it, they do -- typically they have a petty cash budget to buy tools (a WiFi router, a coffee maker, a set of screwdrivers) or small items when the team needs them. This is totally different than the operating budget, which the product owner wields. Tasks they do not have the resources to unblock, they make visible to those who can -- like the product owner, or stakeholders, or any organization above that. By showing the waste created by the block, the person with the resources to solve it can take that task into their backlog and prioritize it against the rest of their work.
Posted on Thu, Sep 20, 2012
by James Rosko
Software Developers and Quality Assurance are sometimes pitted against each other when giving Level-of-Effort estimates. The winner is usually the individual with the strongest personality -- not really a way to give consistent or accurate team estimates.
The way a Scrum team solves the Dev vs. QA effort estimate problem is by incorporating both the Dev and QA estimates in a single Story size. Scrum prescribes Devs and QA to be on the same team, working on the same Story at the same time, and sharing a common Definition of Done (DoD).
I was on a team that went as far as putting the DoD as the first thing you see on the Backlog tool. It was even on a large poster when you walked into the office. Below is an example of a DoD.
DoD -- A user story is Done when:
- All acceptance criteria are met and accepted by the Product Owner
- All acceptance criteria are met and accepted by QA
- 80% of code is JUnit tested
- All happy-path features have automation tests
I encourage you to come up with your own Definition of Done. Your team can review the DoD during the Sprint retrospective. You will see the story sizes become more accurate, you will have fewer assumptions about what should be accomplished for each story, the end product will be more consistent, and, frankly, the Devs and QA will get along better.
Posted on Thu, Sep 13, 2012
by Vibhu Srinivasan
I want to thank everyone who helped me coordinate the Scrum Practitioners Workshop in Hyderabad on 29 August, including our sponsor, the Scrum Alliance. Thanks also go to all the practitioners, speakers, and companies that participated in this great event.
The theme of the day was "Explore and uncover the issues and challenges faced while implementing Scrum and Lean practices in the Indian context". The conference began on time at 9, with all the topics and speakers posted on a huge wall. After a full evening of preparing the hall, we were delighted to see everyone register before 9. We kicked of the day with a daily Scrum, where all the presenters discussed what they were going to talk about.
From the first session by Joe Justice, I was confident that the day would go well. Joe spoke about how he uses Agile practices in his car manufacturing company, WIKISPEED. After this, Naveen Nanjundappa spoke about product ownership in India. Except for a brief technical issue, the session went really well. Post-chai, Jayaprakash Puttaswamy walked the crowd through stages of becoming a ScrumMaster. It was well-received and the audience enjoyed the journey.
Kanchan Khera and Bhuvan Lodha, co-presented a really interesting session called Retro Masala that included both video and audio. They spoke about the many newer retrospective techniques they are trying in their organization.
In the afternoon, we held an “unconference” that included around 14 different sessions — from ScrumFu, to games by Nanda Lankalapalli to Venkat Vatti demonstrating engineering practices. Rafael Sabbagh led a group though his session on Scrum case studies, and Naveen had a group listening keenly to him as he spoke about his topic, You do not know Agile. In addition, many from the audience presented a number of topics, including being green while doing Agile. The last sessions of the day included getting astrological predictions about Scrum and an overview of the metrics that are a must for Agile organizations.
We ended the day with t-shirts, gifts, and thanks. My special appreciation goes to all the volunteers who made this happen. We plan to develop many more insightful workshops in the near future.
Posted on Wed, Sep 12, 2012
by Ambika Patil
SolutionsIQ’s Scrum Practitioners Workshop in Hyderabad on 29 August got the attention of Scrum enthusiasts and was a great success! Many people attended and were eager to discuss their experiences.
Held at the Aditya Sarovar Premiere Hotel, the day began with a keynote via Skype from Joe Justice. In addition to his consulting role at SolutionsIQ, Joe is the founder of green automotive company WIKISPEED, which has revolutionized the auto manufacturing industry by using Agile principles to design and build a high-performance modular car in just three months. He described how he successfully manages critical WIKISPEED project objectives with collaborative distributed teams that iteratively contribute their work every two weeks from locations around the world. The audience was very interested in his implementation of Agile practices in a non-software environment.
Next up were speakers across many domains who brought the desi touch to their topics as they explored the many facets of implementing Scrum in India:
- Product Owner as Scrumdog Millionaire, a session conducted by Naveen Nanjundappa, was about the tasks involved with striking a balance in team and stakeholder interaction.
- Jayaprakash Puttaswamy gave practical insights about the various stages that a person goes through in becoming an effective ScrumMaster in his session, Raju Ban Gaya, ScrumMaster.
- The workshop's theme, “Explore and uncover the issues and challenges faced while implementing Scrum and Lean practices in the Indian context”, was addressed by having guest speakers Kanchan Khera, Bhuvan Lodha, and Nanda Lankalapalli speak about what they’ve experienced in their long Agile careers and the importance of retrospectives.
- Scrum Horoscope, a fun-filled session conducted by Naveen after lunch, saw bright hues of prediction in reading a Scrum team horoscope that warned of impending team disasters.
- The last of the morning’s sessions was a panel discussion conducted by Rafael Sabbagh. The group answered the various questions that were posted on a board throughout the morning by conference participants.
The day became even more interesting when the Scrum Dojo (open space) event began after lunch. The audience was asked to come up with topics of their own and discuss them within groups. Six speakers volunteered to present about the topics that were chosen, and the audience was at liberty to attend the sessions they were interested in. The open space gatherings proved very helpful in understanding the needs of the growing Agile community in India.
Our Scrum Practitioners Workshop was designed to encourage every Agile enthusiast to connect with others who share their passion. We’re pleased we were able to provide a platform for practitioners at every level — from beginner to expert — to partake in the insights that this August gathering offered!
To see more pictures from this eventful day, please visit the Flickr page we created for the conference. You can also learn more about the conference sessions and download presentations at our Posterous page.