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 Thu, May 16, 2013
by David Wylie
Are you a rock star developer? A prodigious code creator, widely read, developer of new frameworks, familiar with many languages? Then you may not need this advice because you are already productive (unless you have an unusual level of humility and desire to improve).
For the rest of us normal folks, there are things we can do better.
The practices that lead to good software are well known:
- Work frequently and closely with requirements providers
- Write automated tests
- Check in small changes and run the tests
- Demonstrate new code and release regularly
- Pair program
Extreme Programming has been around for a long time. BUT MOST DEVELOPERS ARE NOT FOLLOWING THESE AGILE PRACTICES! Sorry, this is bothering me.
If you are not a rock star and don’t follow these practices, you can be better. I bet your code takes longer, has more bugs, and does not meet business expectations as well as it could.
Perhaps it is a marketing failure. The name Extreme, and the initials XP, have connotations that must repel some folks. Current people in management grew up in a time before XP, so they might not like the “communist” components of open work spaces and collective code ownership. Many people became developers because they either don’t want to or suck at dealing with other people, developers or business folks. Those people are not having the positive impact that is within their potential.
Engineers have known good practices that they follow. In fact, if they don’t follow good practices, they can lose credentials and be held liable for failures.
We should hold ourselves to similar standards. We know the practices that work, and it is not a matter of opinion.
Posted on Fri, May 10, 2013
by David Wylie
I think we need to refine how we define teams and team members when they are geographically dispersed. The issue is how best to implement technical practices, work distribution, and communication among team members in different locations. A key Agile principle recognizes that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversations.” How does this apply in a world of distributed teams?
There are many successful implementations of projects where sub-teams are geographically distributed. What they have in common is that the sub-teams have 2-9 people who can work together in the same location. Successful examples (SolutionsIQ, Sutherland, Yap) show that teams/sub-teams in different time zones can deliver regularly with high quality. In most of the projects where teams have participated in remote pairing, the remote team has had two or more people in that location. If you have this situation, these groups should ideally be feature teams, where the group can deliver a complete feature with minimal integration dependencies.
Though remote pairing has been done successfully several times at SolutionsIQ, some of our strongest developers had a challenge with remote pairing. It should be pointed out that on the highest-performing distributed teams, team members start out working together in the same location for a period of time at the start of the project. This allows relationships to develop and norms of practices and behaviors to be established.
We continue to see challenges with scattered teams where individuals are geographically isolated. New technologies like desktop sharing and video (WebEx, Skype, Vuze, VNC, Join.me) help, but our experience shows significant challenges. Chief among them is that having people work from home, a classic pattern, leads to individuals delivering and maintaining expertise. This is contrasted with the team delivering, and sharing of knowledge and responsibility within the team. Individuals can still follow good technical practices like TDD and CI, but positive peer pressure is reduced. Code review and knowledge sharing has to be dealt with separately if pairing does not happen. Team estimation and team velocity are very difficult, and that leads to limitations on release planning. Demonstrations by remote team members are harder but possible. Product owners can ask questions and seek clarifications via conference call, but conference calls can easily become individual conversations. Most of the scattered teams I have encountered do not meet together on regular basis.
If you have remote individuals, then they need to be managed as individuals, not as a team. Wishing for team behaviors will lead to disappointment.
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 Fri, Apr 19, 2013
by Dan Williams
The Agile Manifesto was developed in February 2001 by seventeen people who met to find commonalities between several ‘lightweight’ methods that emerged in the 1990s. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming along with many others were able to agree on a core set of values.[1]
The values expressed in the Manifesto center on people and their interactions within the limiting context of the work environment. This does not mean that the values cannot be applied in other contexts such as the home or school, but it does mean that when speaking of Agile values, frameworks, and tools, we are generally speaking of work environments.
Agile is moving from the software industry, where it got its start, to major corporations providing all manner of goods and services. This shift is partly being fueled by articles in media such as the Wall Street Journal and CIO Journal.[2] Agile is the next big thing (NBT) and is touted as providing that silver bullet of delivering goods and services at the ‘faster, better, cheaper’ pace which seems to be the holy grail of business.
The crux of this article is that Agile is not a process or set of tools to accomplish the goals of business when those goals are limited to mere profit; it is rather a set of values that move us from primarily valuing the work product to valuing the work producer, the person. This may or may not produce improved profit margins. What has been demonstrated is that it does in many cases produce higher quality goods, happier, more fulfilled people producing those goods, and a better business context within which to work.
It is important to understand the fundamental shift in value perspective that Agile recommends to businesses. Process frameworks like Scrum, Extreme Programing and Crystal have been demonstrated to be successful as the Agile values which they promote are understood and incorporated into the business ethos.[3]
If the business attempts to apply one or more of the Agile process frameworks without understanding the need to incorporate the Agile values, the desired organizational change with the anticipated benefits of ‘faster, better, cheaper’ will tend to be minimal. This is due to the dependence of the processes on the values. How can we help businesses with this significant paradigm shift in their thinking? The following suggestions help smooth the way for businesses to move toward incorporating Agile values and processes into their environment:
- Involve all levels of the business, including top level ‘C’ executives. Their sponsorship and support will be important.
- Don’t neglect mid-level management as their support is vital to the success of the transformation.
- Answer the question, “Why move to Agile?” This is important, as the reasons for attempting such a fundamental change should be well understood from both a quantitative as well as qualitative standpoint.
- Understand the current business culture. Change is hard and there will be champions as well as potential saboteurs of the changes to come.
- Spend time on the organizational structure to understand how it helps or hinders the move to Agile.
- Create a roadmap with the explicit understanding that it will change over time.
- Don’t attempt to change everything. Pick an area where a win will be evident and beneficial.
More could and should be said, but this is a short blog article and not an essay. I look forward to continuing this discussion and invite your comments.
Posted on Fri, Apr 12, 2013
by Dan Williams
Last night I attended the Seattle Project Management Institute (PMI) monthly dinner with my wife. As I am a PMP in good standing and hold the new Agile Certified Practitioner (ACP) certification from PMI, I was very interested in the topic and the speakers presenting. The topic for the evening was Creating an Agile Culture. The speakers were Joseph Flahiff, President of Whitewater Projects, Inc.; Ann Konkler, CSM and Agile Coach from Rally Software; and Jim Grams, CTO from Online Shoes.
The speakers shared their perspective of the major cultural shift experienced by companies attempting to implement Agile values and processes. Joseph spoke from the consultant’s viewpoint; Ann spoke as a practitioner and tools provider; and Jim spoke as a manager involved in an Agile transformation effort at his company. All of the speakers were united in their perspectives of the cultural impact of implementing Agile in their businesses.
Joseph defined the culture of a company as all of those factors that provide the context within which people do their daily work. For example, is work given or taken? And what are expectations around work hours, quality standards, communication, reporting, metrics, prioritizing work and respecting sprint boundaries? Joseph emphasized that Agile values are the most impactful part of introducing Agile to a company. In Joseph’s experience, the Agile Manifesto, with its emphasis on respect, collaboration, and value, caused a major cultural shift.
Ann continued the discussion about culture by emphasizing the turmoil that can result during the transition from waterfall techniques to Agile. Fear of change, new methods, higher degrees of communication than before the transition, and new job titles all contribute to the impact that Agile can have on a company.
Jim closed the discussion with examples from his company, which began Agile transformation last year. A key point was that he acts as a shield between upper management and the development team. Management was used to micromanaging and randomizing the team almost on a whim. By enforcing the concept of taking prioritized work and respecting sprint boundaries, rework at Jim’s company has dropped and output has increased 95%. Jim stressed keeping good metrics around improvement in order to show management why Agile techniques are superior.
PMI is actively endorsing Agile as a significant project management technique. The ACP certification places Agile on par with traditional PMP practice; this certification provides a welcome tool that SolutionsIQ can use to help companies transition smoothly to Agile.
Posted on Fri, Apr 05, 2013
by Ron Quartel
There is a smell in Agile around velocity (and estimation) that has not been resolved yet. So what is wrong with velocity? Below are the myriad questions that I get asked whenever teaching velocity that indicate to me that the concept is not particularly simple and that there is a smell (to use a developer phrase).
- How do we account for capacity changes from sprint to sprint?
- What do we do with capacity when the team is particularly cross-functional in nature and has developers and non-developers on it (e.g. testers, business analysts, UI, tech writers)?
- When the backlog is being supported by multiple teams, do we have them aligned around the same sizing, and if so, how?
- Do we measure personal velocity (i.e. by team member)?
- Do UI points differ from testing points, tech writing points, etc.?
- Do we track actual and estimated velocity?
- How do we track/account for stories that spill over with regards to velocity, and what size the stories end up being?
- Do we get credit for part of the story that was complete (when we don’t hit commitment)?
- Do we burn up points and then stop work on the story when we have delivered that many points of value?
- Do we put points on spikes and/or research tasks?
- Do we put points on bugs?
- Do we put points on non-dev activities that are in the sprint but required to get to completion?
- Are points just complexity, or is there little complexity and a lot of repetition or time?
- If we change team members do we need to recalibrate the points?
- If we take velocity as an average of the sprints, how do we account for different capacities in the sprints?
- Is velocity a rolling average or the average from day one forward?
- If rolling, how many sprints should we use?
- Do we need to reset the velocity when the team changes?
- Can we have an exchange rate on our points to another team’s points?
- Points aren't real, so why should we use them?
- If we do extra work in the sprint that wasn't planned for, do we get credit for it?
- Should the goal be to increase velocity each sprint?
- If multiple teams are working off the same backlog, do they have to be using the same point values?
I have answers for all these questions and I am not going to go into them here. My point is that the concept of velocity is not as simple as it seems on the surface, and in fact has some serious flaws.
So what is the solution?
If velocity is not a problem for your team because you have found something that works, then yay! Stay with it. I have seen it work well and not so well. It seemed to work best in teams that were comprised solely of developers that were pair programming (e.g. XP teams).
Switching to Kanban will resolve many of the issues, but only if Kanban fits your release process. Unless you are making use of inspect and adapt at the end of an iteration (which is what iterative development gives you) then you may as well ditch iterative development and go with a flow system like Kanban. Or, if you release to a heartbeat cycle and whatever is done by the next release point gets in, Kanban might be a better fit also. Kanban has a different approach to throughput than velocity, that does not raise all the questions above – hence the recommendation, but only if the process fits.
Otherwise, watch this space, or please let me know if you have any ideas or have seen something that works to resolve this aspect of iterative development.
Posted on Fri, Mar 29, 2013
by Steven M. Smith
In my last post, I examined the lessons teams can learn from the historical examples of British Prime Minister Margaret Thatcher and FEMA Deputy Director Michael Brown. In this post I will continue to analyze the patterns resulting from the interaction of three variables: ability, demand, and support.
The Scuttled Pattern (Carly Fiorina, 1999-2005)
Carleton (Carly) Fiorina was CEO of Hewlett-Packard (HP) from 1999-2005. Her command ship was scuttled in 2005 when she lost the support of HP’s board.
Prior to HP, Fiorina was the executive vice president at AT&T responsible for spin off and initial public offering of Lucent Technologies. She joined Lucent’s executive management team where she was chairman of a joint venture and later a group president for its global service provider business. I think it’s fair to say she was a person of proven ability.
When she became CEO of HP, the demands on the business were considerable. HP had been unsuccessful at exploiting the Internet; it had lost ground to perennial rivals IBM and Sun Microsystems; and Compaq and Dell Systems were growing, thus eroding HP’s share of the PC market.
In 2001, Fiorina’s plan was to break up HP and merge the parts she kept with PC maker Compaq. HP board member Walter Hewlett (the son of the “H” in HP) publicly objected to the merger, describing it as an act of desperation. David Packard (son of the “P” in HP) publicly said that the merger plans were a cruel departure from the values and corporate culture of HP’s founders.
Describing the situation, Fiorina said, “Most of the media… is positioning the merger with Compaq and the recent actions by Walter Hewlett and David Packard as a fight between the past and the future.”
Fiorina won the battle for the future, but it was a Pyrrhic victory. The win had cost her support. She continued to win battles, but lose supporters. Each lost supporter drilled another hole in the hull of her command ship. Eventually the bilge pumps couldn’t keep up and the ship sank.
What lessons can teams learn from Carly Fiorina’s HP experience? Support is precious. Find strategies that supporters believe are right even if they aren’t your favorites. Constant fighting with supporters, especially public brawls, will eventually scuttle your ship.
The Bored Pattern (Winston Churchill, 1945-1949)
After successfully leading Britain through World War II, Winston Churchill’s Conservative Party lost the election and he was forced to step down as Prime Minister. It crushed him. Without popular support and the high-demands of being Prime Minister, he grew frustrated and bored.
Never a ray of sunshine, his sarcasm and black moods increased. Although he remained in Parliament, he brooded over the atomic bomb, the Soviet menace, and creating “a United States of Europe.” But he had enormous amounts of free time compared to the war years as Prime Minister.
He channeled his unused ability into writing and painting. He was excellent at both. He was awarded the Nobel Prize in Literature and his impressionist paintings have been exhibited around the world and continue to attract attention. On painting, he said, “Armed with a paint-box, one cannot be bored, one cannot be left at a loose end, one cannot ‘have several days on one’s hands.’”
But things change. Uncertainty about foreign threats created demands that matched his ability. Support began building. In 1951, his Conservative Party won a majority and Churchill returned to being Prime Minister.
What lessons can teams learn from Winston Churchill’s post-World War II experiences? Don’t waste your talent and skill. Focus your unused ability on activities that provide you with a sense of accomplishment. Keep supporters aware of your abilities. Things will change.
The Energized Pattern (Mahatma Gandhi, 1915-1945)
Mohandas (Mahatma) Gandhi energized and led the Indian subcontinent out of British domination. I consider him the greatest change agent of the Twentieth Century.
After ten years of leading the civil rights movement in South Africa, Gandhi returned to India in 1915. He faced daunting demands. British dominance had become the status quo for two generations of people born on the Indian subcontinent. And Britain was determined to maintain its dominance by all means necessary.
Using methods of nonviolent resistance, a philosophy of fearlessness, and his personal example, Gandhi’s Indian independence movement gained more supporters. And with more support came new demands, which called for him as leader to develop new skills. One generation after his return, the movement won its independence.
I question whether anyone would have said in 1915 that Gandhi had the ability to successfully lead a movement of this size and complexity. But I believe he convinced himself that he could and in the process energized himself and his followers to develop the necessary skills.
Gandhi said the following about acquiring ability: “Men often become what they believe themselves to be. If I believe I cannot do something, it makes me incapable of doing it. But when I believe I can, then I acquire the ability to do it even if I didn’t have it in the beginning.”
What lessons can teams learn from Mahatma Gandhi’s struggle for Indian independence? Have faith. Believe in yourself. Set an example. Use the difference between your perceived skills and your desired skills as energy for bridging that gap.
§
What’s the difference between the cases of Thatcher and Gandhi versus Brown, Fiorini and Churchill? Support. If your team is failing to nurture support, you will fall.
What’s the difference between the cases of Thatcher and Gandhi? Thatcher had an existing (governmental) structure to use to implement her policies. Gandhi had to create a new structure. Thatcher was clearly skillful and energized, but Gandhi’s movement seems to me to have required much more energy.
Did Brown fail because he didn’t believe in himself like Gandhi did? No, I suspect Brown did believe in himself. He may, however, have suffered from hubris. With better support, he may have been able overcome the demands that swamped him. But he apparently didn’t foster that support.
What does the case of Churchill tell us? An active life is bound to have setbacks. The period described wasn’t Churchill’s first setback. With support, our abilities can be applied to larger demands.
What would you add to this analysis?
Posted on Fri, Mar 22, 2013
by Steven M. Smith
History provides lessons for teams. Let’s take the time to explore a few of them. This post explores patterns that I see resulting from the interaction of ability, demands and support. Let me explicitly state what I mean by those variables –
- Ability is the capacity to do something through talent and skill.
- Demands are the problems that must be solved or managed.
- Support is active help and encouragement.
The historical cases below deal with individual leaders, but each leader represent the many people who worked with the leader to achieve some end. Please note that the cases only refer to the point-in-time referenced.
The Skilled Pattern (Margaret Thatcher, 1979-1990)
Margaret Thatcher skillfully led Britain as its Prime Minister from 1979-1990. She was more than able — she was a brilliant organizer, a first-class speaker and utterly focused.
When she became Prime Minister in 1979, the demands on her were formidable and included nationalized industries that couldn’t compete with their global counterparts; a history of bitter labor strikes against nationalized industries; a burdensome and growing tax on the private parts of the economy; potential loss of supporters as she made changes; and the Cold War.
Thatcher addressed these demands by privatizing nationalized industries, facing off against the powerful trade unions, reforming the tax structure, gaining new supporters by selling public housing to its renters, and supporting the reforms of Soviet leader Mikhail Gorbachev.
I think Thatcher’s personality shone through when she said, “Look at a day when you are supremely satisfied at the end. It’s not a day when you lounge around doing nothing; it’s when you’ve had everything to do, and you’ve done it.”
What lessons can teams learn from Margaret Thatcher’s experience as Prime Minister? Know your mission. Execute it skillfully. Constantly be looking for ways to gain new supporters.
The Swamped Pattern (Michael D. Brown, 2003-2005)
Michael D. Brown was the Deputy Director of the Federal Emergency Management Agency (FEMA) who was swamped during the Hurricane Katrina disaster of 2005. Brown appears to have had virtually zero background in emergency management prior to his appointment as Deputy Director of FEMA in 2003, the bulk of his career having been spent practicing law and as Commissioner for the International Arabian Horse Association.
Up until Hurricane Katrina, FEMA had been considered a model federal agency because of its successful responses to past disasters such as the Midwestern floods of 1993, the Northridge earthquake of 1994, and the Oklahoma City terrorist attacks of 1995. When the demands from Katrina became known, FEMA’s response was considered by many, especially by the residents who were caught in the path of its destruction, an utter failure.
Email messages sent by Brown during the disaster tell something about his ability. He wrote, “Can I quit now? Can I go home;” and “trapped (as FEMA head) … please rescue me.” I can’t imagine any circumstances in which Margaret Thatcher would have ever sent similar messages. Fewer than 45 days after sending the email message, swamped and resigned, Brown quit his Deputy Director position.
Did Brown have all the support necessary to respond satisfactorily to the demands caused by Hurricane Katrina? No, I don’t think he did. The organization of federal emergency agencies had change considerably after the September 11, 2001 terrorist attacks. Regardless, I think his poor ability eroded the support he could have had and prevented him from maximizing the support he did have.
What lessons can teams learn from Michael Brown’s Hurricane Katrina experience? Know your ability. If your demands outstrip your ability, find more support or find a different mission.
§
In my next post I’ll introduce a few more historical examples and ask for your input on the differences between their experiences balancing ability, demands, and support.
Posted on Wed, Mar 13, 2013
by Garrick West
A disclaimer on the term ‘hacker’
Unfortunately, the popular media has largely corrupted the original definition of the term hacker from its programming subculture grown out of MIT in the 1960s. My comparison here is to the true, original meaning of the term as it grew out of academic culture.
Re-reading: Seeing the world of a book through the eyes of new experiences
I’m not a frequent re-reader of books I pick up for pleasure. There’s a small list of books I have read multiple times, but Steven Levy’s Hackers: Heroes of the Computer Revolution was one book on the “must-re-read” list. I remembered enjoying it thoroughly as a college computer science student when I picked it up wanting to learn more about the history of computing outside the textbook pages. I planned to read it again one day, but that had been, well, ahem…let’s just say a few years ago. As I began reading again years later, I sensed something familiar, a similarity between some of the fundamentals of the hacker ethic being described and the principles of the Agile Manifesto I had been fortunate to operate under for many years. Here’s a summary of the hacker ethic and a comparison to a number of Agile Manifesto principles.
Levy’s principles of the hacker ethic
Levy’s hacker ethic is best summarized by the Wikipedia article on Levy’s book, which ascribes the following principles to the ethic:
- Access to computers—and anything which might teach you something about the way the world works—should be unlimited and total. Always yield to the Hands-on Imperative!
- All information should be free.
- Mistrust authority—promote decentralization.
- Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race or position.
- You can create art and beauty on a computer.
- Computers can change your life for the better.
Comparison to the Agile Manifesto principles
Now let’s see how these match up to the principles behind the Agile Manifesto:
1. Access to computers—and anything which might teach you something about the way the world works—should be unlimited and total. Always yield to the Hands-on Imperative!
The first principle matches fairly well in spirit with “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Motivated individuals, support and trust all resonate strongly with access and the ‘Hands-on Imperative’.
2. All information should be free.
3. Mistrust authority—promote decentralization.
These have a lot in common with “business people and developers must work together daily throughout the project” and “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” It’s hard to keep information locked away when you have constant communication (and high bandwidth communication at that). And in terms of organization, Agile is all about decentralizing.
4. Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race or position.
This theme of populist drive and democratization is specifically captured by two principles, “working software is the primary measure of progress” and “the best architectures, requirements, and designs emerge from self-organizing teams.” It’s all about what works, and the knowledge that any individual can make a strong contribution.
5. You can create art and beauty on a computer.
I think this is well-embodied in “simplicity—the art of maximizing the amount of work not done—is essential” and “continuous attention to technical excellence and good design enhances agility.” These principles both speak to the notes of craftsmanship in building software, where there is a place and a need for art and beauty.
6. Computers can change your life for the better.
Last but not least, the first Agile principle mentioned seems to match this hacker principle well: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” That is, of course, if you think that satisfying your customer and delivering valuable software early and continuously improves the part of your life spent in the creation of software.
Correlation, or just coincidence?
It’s not a direct adaptation by far. In fact, a lot of the classic hacker ethic displayed in early chapters of the book demonstrates things we don’t encourage in Agile principles, like 30-hour-day cycles. Also, there’s no mention of reflecting on how to become more effective, and the hacker ethic is of course a personal ethic as opposed to a set of principles shared by an Agile team. But all in all, I think there’s something to be said for the spirit shared between the two. Perhaps one day I’ll learn what members of either group think about comparison to the other. Until then, feel free to comment and talk amongst yourselves.
References:
Image courtesy of believekevin