This article, posted on Oikosofy’s blog, gives a pretty good introduction into the way things were in manufacturing and the way things are now. In “Agile-Manager — What is an Agile Manager?” he goes back to the time of FORD to explain how things have progressed.
It shows that not only have agile methods changed the way things are made, but they have also changed the corporate environment which houses the teams who make the products.
He also address how so many businesses now offer services and how that effects development.
I found this article insightful and worth a read.
What is agile exactly? How do we practice it? What does it look like to be an agile product owner? What is an agile team?
One of the qualities I’ve come to admire the most about agile teams and agile ambassadors is this continuous state of learning which everyone agrees to be in.
It seems as though “being agile” gives us permission to sometimes know an answer and sometimes not to. It gives us permission to sometimes understand a situation and have a solution and sometimes not to. Agile methods have a built-in “Reality Check” which is so refreshing.
By openly communicating often in retrospectives and by making work and backlog visible the process is taken out of the abstract and into the concrete. Agile seems to put everyone on the same page ~ even if people are coming at agile from very different angles.
Recently I posted a question to the 2500+ members of the Facebook Scrum group, asking for good recommendations for meaningful resources.
Here are the TOP Four Responses:
I’m interested to read your comments about any of these four articles or sites. What do you agree with? What do you disagree with?
What has been your biggest challenge and greatest success with implementing agile methods in your work environment?
Dozens of individuals receive training to become Certified Scrum Product Owners at our public learning events in Toronto, Ontario.
What is a Product Owner? And how do they create a product vision in alignment with the team they work with? Xi Zeng, over at 3 Agile Guys blog, has some ideas worth sharing.
Here is an excerpt from his article on product vision.
A project always has a predefined scope and goals, therefore defining a vision for a project is in most of the cases not really necessary. A product has usually a much bigger scope and a longer life cycle, so it’s important to create a product vision in advance in order to:
- help the business define requirements
- be able to evaluate the value of the project
- simplify the communication among the organisation (or with clients)
- act as project’s compass
- support the prioritization and decision-making in projects
The vision should consider the long term life cycle of the product and should not be easily reachable. Define even a vision that is almost impossible to reach. All short term goals should be clear defined and measurable, e.g. what is the next step in the project, next valuable goal, how to prioritize work items in backlog, etc. But the vision represents the long term future, it should stay ambitious. Just like when you’re hiking on the mountains, you can see the rocks under your feet, you know their size and form, you can touch them and even pick them up. But you can only see roughly where is the top of the mountain. While hiking, reaching the top of the mountain is our vision.
I think there is a lot of value in what Xi writes and it is worth exploring in greater depth.
On the blog “Fragile” the author writes about the human side of Agile. The author, who does not name themself anywhere on the blog, criticizes the agile movement for not giving more time to the issue around management.
Here are some of the key arguments:
The author also notes that an anecdote they wrote was included in a recent book. It basically describes a way to make the most of an environment even if management is not providing funding or space to support agile implementation.
Here is the antidote:
It may not always be possible to create the perfect working environment, however it is important to make the most of what is available. My team were looking to map their work flow using a white board and sticky notes. Unfortunately we were situated in the middle of an open plan office without access to walls, nor did we have the necessary space for a for a free standing white board. In the end we bought a roll of white board sheeting and applied it to a nearby structural pillar. Work items flowed from top to bottom and space was tight, but it served our purpose and is still in use years later.
Scrum suggests the size of the Development Team (the Scrum Team members who perform the work of the Sprint Backlog) be between three (3) and nine (9) people. (The Scrum Master and Product Owner are not included in that count unless they are also executing the work of the Sprint Backlog.) To maximize cohesion and minimize complexity, it is important larger groups be split into smaller units or downsized.
Considerations for re-organizing into multiple Scrum Teams:
For those who are not familiar, The Scrum Team Assessment is your virtual Scrum coach! Using this simple assessment, you can find out how your team is doing and ways to improve.
Recently, new upgrades have been added to the Scrum Team Assessment and it is available for use free of charge for a limited time.
The features of the Scrum Team Assessment include:
Read more about the Scrum Team Assessment and try it for your team!
Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there. For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust. For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework. This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results.
To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behaviour of the team and all of the supporting roles (that includes their leadership). Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values.
Needless to say this can become an extremely complex challenge! To be absolutely clear, I’m not proposing there is a single formula or recipe that works, but I do believe certain criteria can dramatically improve your Scrum team’s chances of success. To that end here are 10 tips (plus a bonus) that may help you focus your efforts towards building a successful Scrum team and experience.
1. Right Number of Team Members
Currently the Scrum Guide recommends that Scrum teams will work best with three to nine people (not including the Scrum Master and Product Owner). Too few people on the team and you risk not having enough technical expertise and coverage of critical skills. Too many people on the team and you may become challenged to truly collaborate effectively. Remember, this is just a guideline and you may be successful with different numbers, you just need to be aware of the impacts and make sure the gaps are covered.
2. Appropriate Balance of Skills
Scrum teams really should be balanced and cross-functional. Having all of the necessary skills on the team for delivering a complete solution (not roles, but skills) will encourage and support end-to-end thinking all the way from design to implementation. This approach will result in a better solution and a superior customer experience, but it relies on whole team collaboration. Note this does not mean individual team members need to be fully cross-functional, but what is important is that all the critical skills are represented on the team and each team member contributes their domain expertise towards the collective strength.
3. Propensity for Engineering Technical Ability
For increased chances of success, a Scrum team should leverage technology and engineering practices whenever possible. Techniques, skills and tools that facilitate Agile approaches such as Continuous Integration, Automated Testing and Test Driven Development all make technical excellence, continuous improvement and truly being “Done” every Sprint a possible reality for a Scrum team.
4. High Team Member Allocation
Scrum team members should be allocated to as few different initiatives as realistically possible. The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be. In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most. This is true for any framework, but it is particularly emphasized with Agile ones. Note there is a slight but fundamental difference between being allocated to a team and being dedicated to a team – that is a topic for a future article.
5. Empowered and Knowledgeable Product Owner
Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in. They also need to be a strong negotiator and very capable at conducting business driven trade-offs. In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created. Without empowerment, knowledge, and vision in a Product Owner the team will struggle.
6. Equitable Scrum Master
Having a good process is only part of the equation. A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.
Remember that the Scrum Master has authority over the process but not over the team. As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working. In that regard a Scrum Master should understand and embrace the servant leader role. In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them.
7. Strong Executive Support
Leadership is the key to driving change and progress. Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.
Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures. And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.
8. Solid Partnership Commitment
There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking. The initiative must be an open, collaborative experience and there must be complete understanding and alignment by all parties in assuming the risks and rewards as well as sharing in the effort. This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative.
9. Reduced Team Dispersion
Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room. More simply stated, the greater the dispersion factor, the greater the challenge of collaboration. Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.
Although it is strongly recommended that teams be co-located, it is not mandatory to success. In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication. But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it.
10. Consistent Education and Coaching
To ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training. Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits. Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.
11. The Right Attitude!
Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs. Not just saying but living the belief there are no heroes or scapegoats. Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.
Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate.
At the end of the day your goal should not be to become Agile or Scrum savvy. Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers. These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention. Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.
For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach. To be clear, this is not easy to do but the rewards are well worth the effort. By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.
Can you think of other success factors that might help your Scrum team succeed? There are lots, so feel free to reach out and share them below.
Thanks to Photographer: Chris Potter for this awesome photo.
Sourced from stockmonkeys.com | Flickr Portfolio
Lately I’ve been appreciating the Top 100 Agile Websites compiled by Oikosofy.
Just out of curiosity, I thought I’d check out Number 100, just to see who was the lucky guy who wasn’t listed as number 101.
What I found was a delightfully surprising and pleasantly entertaining blog by a coach named Yves Hanoulle. One article which particularly caught my attention is called “Getting out of your comfort zone.”
His reflections after a training seminar on the topic really made a lot of sense to me.
Basically, an agile team is striving to create a Safe Zone for themselves and their team-mates so people will take risks and move out of their comfort zone. In order to do this, they are or become really comfortable with that uneasy state of being uncomfortable.
It’s as though it is no longer uncomfortable to be uncomfortable.
When an agile team moves out of its Comfort Zone together and everyone feels safe and supported, the end result is the type of team described in the Agile Manifesto. It’s the type of team companies really get excited about. It’s the type of team people love to work with and in doing so they may find they love their work more than ever.
I recently said goodbye to one of my organization’s Agile Coaches and I felt that I needed to take a pause and reflect to consider my next move. The engagement had gone well, in fact one of the best we’ve had, but not without its share of successes and failures. But the successes had clearly outpaced any failures, and so there was a lot of good I wanted to build on.
The departing coach was part of a 3rd generation of Agile Coaches that I had worked with in the 3 years since we had begun our company’s transformation to Agile. And while he was a great coach, so were his predecessors and yet they had had fewer successes.
On reflection, what had really happened is that we had changed as a company; we had learned how to better execute our engagements with an Agile Coach.
Deciding to hire an Agile Coach can be a big step. A couple of things need to have happened, you’ve recognized that you need some help or at least another perspective. And given that Agile Coaches are typically not very cheap, you have decided to invest in your Agile transformation, however big or small. You’re clearly taking it seriously.
However, through my experiences I noticed that things can get a little tricky once that decision has been made. Many organizations can fall into a trap of externalizing transformation responsibilities to the Agile Coach.
In essence thinking along the lines of “as long as I hire a good coach, they should be able to make our teams Agile” can take you into an engagement model that is not very Agile in the first place.
Much like how Scrum and other Agile Practices connect customers with teams and establishes shared risk, an organization’s relationship with their Agile Coaches need to be a working partnership.
So it’s important for you to setup the right engagement approach to get value out of your Agile Coach and this goes beyond the hard costs of their services, but also the high cost of failure with not having the right coaching in the right areas.
Here are 5 positive patterns for coaching engagements that I’ve observed:
Usually it is management who will hire a coach, and they may do so to help one or more teams with their Agile adoption needs. So in this scenario who is the customer? Is it the person that hired the coach or the teams (the coachees) who will be receiving the services? In some cases, the coachees aren’t clear why the coach is there, they haven’t asked for their services and in some cases may even feel threatened by their presence.
For this reason, if management is hiring coaches you need to recognize that there is a 3-pronged relationship that needs to be clearly established and maintained.
With the customer in this case being someone in management, i.e. the person who hired the coach in the first place. The customer’s responsibility will be to not only identify the coachee but then work with the coach to establish and support that relationship.
Agile Coaches typically tend to be more effective when they have one or two specific mandates tied to an organization’s goals. Not only is the mandate important to establish why the coach is there, too many goals can significantly dilute the coach’s effectiveness. Put another way, Agile Coaches are not immune to exceeding their own Work in Progress limits.
The mandate establishes why the coach is there, and should be tied to some sort of organizational need. A good way of developing this is to articulate what is currently happening and the desired future state you want the coach to help with.
The teams on our new program are great at consistently delivering their features at the end of each sprint. However, we still experience significant delays merging and testing between teams in order for the program to ship a new release. We’d like to reduce that time significantly, hopefully by at least half.
Once the engagement is well underway you may find that the coach, through serendipity alone, is exposed to and gets involved with a wide variety of other areas. This is fine, but it’s best to just consider this to be a side show and not the main event. If other activities start to take on a life of their own, it’s probably a good time to go back to inspect and potentially adjust the mandate.
If you’re not sure how to establish or identify your Agile goals, this could be the first goal of any Agile coach you hire. In this scenario, the customer is also the coachee and the mandate is to get help establishing a mandate.
Agile coaches are not a homogeneous group, with many degrees of specialty, perspective and experiences. Resist the desire to find a jack-of-all-trades, you’re as likely to find them as a unicorn.
Your now established mandate will be your biggest guide to what kind of coach you should be looking for. Is the need tied to technical practices, process engineering, team collaboration, executive buy-in, transforming your culture, etc?
The other part is connected with the identified coachee. Are the coachees team members, middle management or someone with a “C” in at the start of their title? Will mentoring be required or are you just here to teach something specific?
Using something like ACI’s Agile Coaching Competency Framework, would be a good model to match the competencies required of the perspective coach.
In my example earlier, in order for your team to get help with their merging & testing needs, you may have to look for a coach with the right skills within the Technical Mastery competence. And if you have technical leaders who are championing the change, potentially the ability to Mentor.
With the coach, customer and mandate clearly identified, you now need to be ready to devote your time to regularly connect and work with the coach. Formalizing some sort of cadence is necessary, if you leave it to ad hoc meetings you will typically not meet regularly enough and usually after some sort of failure has occurred.
The objective of these feedback loops is to tie together the communication lines between the 3 prongs established: the customer, the coach and the coachees. They should be framed in terms of reviewing progress against the goals established with the mandate. If the coachees ran any experiments or made any changes that were intended to get closer to the goals, this would be the time to reflect on them. If the coachees need something from the customer, this would be a good forum to review that need.
Along with maintaining a cadence of communication, feedback loops if done regularly and consistently, could be used to replace deadlines, which in many cases are set simply a pressure mechanism to maintain urgency. So statements like “Merge & test time is to be reduced by half by Q2” now become “We need to reduce merge and test time by half and we will review our progress and adjust every 2 weeks.”
Resist the temptation to set the coach’s hours as a full-time embedded part of the organization or team. While you may want to have the coach spend a significant amount of time with you and your coachees when the engagement is starting, after this period you will likely get a lot more value from regular check-ins.
This could look like establishing some sort of rhythm with a coachee: reviewing challenges, then agreeing on changes and then coming back to review the results after sufficient time has passed.
This approach is more likely to keep the coach as a coach, and prevents the coach from becoming entangled in the delivery chain of the organization. The coach is there to help the coachees solve the problems, and not to become an active participant in their delivery.
Bringing in an Agile Coach is an excellent and likely necessary part of unlocking your Agile transformation. However, a successful engagement with a coach will have you more connected and active with your transformation, not less. So consider these 5 positive coaching engagement patterns as I consider them moving into my 4th generation of Agile coaches. I expect it will be a lot of work, along with a steady stream of great results.
March 9, 2016, I took advantage of a free webinar offered by the Scrum Alliance, with the above title. We were told 5,000 people were attending! Angela Johnson’s presentation was based on information from both the Scrum and psychology communities.
First, she reiterated many ideas that are commonly understood about the role of a ScrumMaster (SM): an internal coach, a servant leader, an active facilitator. The SM makes sure that the rules of Scrum are followed by a team, but focuses on interactions and outcomes. As in football, the SM is truly a coach.
She described how new SM’s often latch onto the mechanics of Scrum, but most important are the personal interactions of a team. When difficulties arise, it is important to ask: “Do we have a Scrum problem, or is it a people problem?”
Ms. Johnson cited two resources available to SM’s to understand people interactions and problems better. One is the previous publication by Dale Carnegie called “How to Win Friends and Influence People.” The other is a newer resource by Michael James available online as scrummasterchecklist.org. In it James covers ideas like “How is my team doing?…How is the product owner doing?…etc”
She also cited a fascinating book by Harvey Robbins and Michael Finley called “’The New’ Why Teams Don’t Work.” She spoke about the importance of goals and objectives for a team. Bad Teams have vague goals and objectives. Good Teams may have clearer goals and engage in barrier identification. But the Best Teams have clear, short-term goals with continuous high-priority goals and objectives in segments of 30 days or less; they also identify barriers to people and processes. Best Teams ultimately value differences among team members, and develop something she called “versatility plans in interpersonal relationships.” (I wanted to learn more about this idea and posed a question in the webinar which unfortunately went unanswered.)
She then turned to psychology to discuss behavioral style differences in people. Four distinct personality types were explored: the Analytical (asks how?), the Driver (asks what?), the Amiable (asks who?) and the Expressive (asks why?). She believes a SM might help team members identify which personality quadrant they belong in so as to better understand each other. As well, in knowing the type of people who are in his/her team, a SM could adjust his/her communication and behavior to better reach each type.
I think it would be an interesting exercise for a team to go through personality types at least once. The exercise itself, besides creating deeper understanding, could also lead to some “aha” moments and laughter.
Johnson went through a checklist of Harvey Robbins’ rules for building trust in a team or group of people, and I will list them here:
have clear, consistent goals
be open, fair, and willing to listen
be decisive (meet the definition of Done)
support all other team members
give credit to team members when due
be sensitive to the needs of members
respect others’ opinions
empower team members to act
adopt a “we” mentality
take responsibility for team actions
She then added tips about supporting versatility: a) you can only create an environment that encourages self-motivation rather than motivate others directly; b) assist people to interpret what you say, i.e. “What I’m about to say is to help…etc;” c) don’t overlook a variety of orientations, whether they are cultural, or gender-based. She advised that we need to be aware that orientation is very important to consider as the teams we work with have a greater number of people whose first language is not English.
She spoke about Scrum teams working within larger organizations. If the goal of Scrum is to produce greater value more quickly, then a SM should never have his/her attention split between more than one team. The SM has to be a teacher inside of an organization, to help management understand best practices – the SM is really the coach for a team, the Product Owner and the organization. Old habits die hard, so educating takes time.
Don’t allow language to get in the way of this process. Don’t say: “That’s not Agile! That’s not Scrum! You’re doing it wrong!” Instead say, “When you say Agile, what do you mean?” or, “What is the problem we’re trying to solve?” A SM can always point out that we have a choice to work in the old way, or to try something new. We have an opportunity to improve the way we work.
Agile and Scrum, she emphasized, are not destinations – they are about continuous improvement.
This summarizes just some of the valuable ideas Angela Johnson presented.
In just a few weeks we will be hosting Craig Larman here in Toronto as he facilitates the first-ever-in-Canada Certified Large Scale Scrum Practitioner training! Large Scale Scrum (LeSS) is about de-scaling. In simple terms, this is about using Scrum to make the best possible use of the creativity, problem-solving and innovation abilities of large numbers of people, rather than getting them stuck in bureaucracy and management overhead.
Here are the details of this unique learning event:
Here are some quotes from previous attendees:
“It was inspiring to discuss Large-Scale Scrum with Craig Larman. The content of the course was top-notch.” – Steve Alexander
“The delivery was outstanding and the supporting material vast and detailed.” – Simone Zecchi
“The best course I have ever been on. Totally blown away.” – Simon Powers
Toronto is a great place to visit (I know many of our Dear Readers are from the United States) – don’t hesitate to consider coming in for a weekend as well as the course!
Register now! (Goes to our BERTEIG / World Mindware learning event registration site.)
The Perfect Agile Tool doesn’t yet exist. In my training and consulting work, I often have strong words to say about electronic tools. Most of the tools out there are really bad. Unfortunately, JIRA, the most common tool, is also the worst that I know of. (Actually, the only tool worse than JIRA for an Agile team is MS Project – which is just plain evil). Some Agile tools do a bit better, but most fall far short of a good physical task board (information radiator). I am often asked to evaluate and / or partner with tool vendors to “bless” their products. Here is what I am looking for before I will consider an outright endorsement of such a tool.
This list is roughly organized in order of features which do show up in some tools to those which I have never seen or heard of in tools.
The tool should display the current work of an Agile team in a way that is immediately recognizable as a set of note cards or PostIt’s on a physical wall. This includes colours, sizes, etc. Most people will type to enter data so fonts should be chosen to mimic hand-printed letters. Every aspect of the display should remind people of the physical analogue of the tool.
As team members are using the tool, all updates that they make should be visible as immediate updates to all the other team members including typing, moving cards around, etc. There is no off-line mode for the tool. In fact, if the tool is not receiving live updates, it should be clearly disabled so that the team member knows there is a problem with the information they have displayed.
Most Agile methods strongly de-emphaisize or even disallow traditional roles and encourage self-organizing teams. This means that fine-grained access control to different features of the tool should be eschewed in favour of extremely simple access control: everyone can do anything with the tool. (It actually helps if there is no “undo” feature, just like there’s no easy way to erase Sharpie written on a note card.)
When you are using cards on a wall, it is easy to see the whole wall or to get up close and see even very fine details on a single note card. Although it does not have to be literally infinite, the wide and tight zoom levels in the tool should be at least a few orders of magnitude difference. As well, the zoom feature should be extremely easy to use, similar perhaps to the way that Google Maps functions. Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.
This seems like a super-obvious feature in this day and age of tablets, smart phones and touch-screen laptops. And it would take the cards on the wall metaphor just that extra little way. But very few tools are actually easy to use on touch devices. Dragging cards around and pinch to zoom are the obvious aspects of this feature. But nice finger-drawing features would also be a big plus (see below)!
For techies, this one is extremely counter-intuitive: limit the amount of information that can be stored on a “card” by the size of the card. It shouldn’t be possible to attach documents, screen shots, and tons of meta-data to a single card. Agile methods encourage time-boxing (e.g. Sprints), work-boxing (e.g. Work-in-Process limits), and space-boxing (e.g. team rooms). This principle of putting boundaries around an environment should apply to the information stored on a card. Information-boxing forces us to be succinct and to prefer face-to-face communication over written communication. Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.
Information-boxing also applies to meta-data. Cards should not be associated with users in the system. Cards should not have lots of numerical information. Cards should not have associations with other cards such as parent-child or container-contained. Cards should not store “state” information except in extremely limited ways. At most, the electronic tool could store a card ID, card creation and removal time-stamps, and an association with either an Agile team or a product or project.
Almost every electronic tool for Agile teams puts cards in columns. Get rid of the columns, and allow cards to overlap. If there is any “modal” behaviour in the tool, it would be to allow a team member to select and view a small collection of cards by de-overlapping them temporarily. Overlapping allows the creation of visually interesting and useful relationships between cards. Cards can be used to demarcate columns or groupings without enforcing strict in/out membership in a process step.
Increase the fidelity of the metaphor with physical cards on a wall. Rotation, folding and ripping are all useful idioms for creating distinct visual cues in physical cards. For example, one team might rotate cards 45 degrees to indicate that work is blocked on that card. Or another team might fold a dog-ear on a card to indicate it is in-progress. Or another team might rip cards to show they are complete. The flexibility of physical cards needs to be replicated in the electronic environment to allow a team to create its own visual idioms. Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.
Cards should allow free-form drawing with colours and some basic diagramming shapes (e.g. circles, squares, lines). Don’t make it a full diagramming canvas! Instead, allow team members to easily sketch layouts, UML, or state diagrams, or even memory aides. The back side of the card is often the best place for more “complex” sketches, but don’t let the zoom feature allow for arbitrarily detailed drawing. Lines need a minimum thickness to prevent excessive information storage on the cards.
With Siri and other voice-recognition systems, isn’t it time we also built in handwriting recognition? Allowing a team member to toggle between the handwriting view and the “OCR” view would often help with understanding. Allow it to be bi-directional so that the tool can “write” in the style of each of the team members so that text entry can be keyboard or finger/stylus.
This is the most interesting feature: allow a photo of cards on a wall to be intelligently mapped to cards in an electronic tool (including creating new cards) and for the electronic tool to easily print on physical note cards for placement on a wall. There is all sorts of complexity to this feature including image recognition and a possible hardware requirement for a printer that can handle very small paper sizes (not common!)
These are the features that many electronic tools implement as part of being “enterprise-ready”. I’ll be brief on these points:
No Individual Tracking – the team matters, not who does what.
No Dependency Management – teams break dependencies, tools don’t manage dependencies.
No Time Tracking – bums in seats typing doesn’t matter: “the primary measure of progress is working software” (or whatever valuable thing the team is building) – from the Agile Manifesto.
No Actuals vs. Estimates – we’re all bad at predicting the future so don’t bother with trying to get better.
No Report Generation – managers and leaders should come and see real results and interact directly with the team (also, statistics lie).
No Integration Points – this is the worst of the anti-features since it is the one that leads to the most anti-agile creeping featuritis. Remember: “Individuals and interactions [are valued] over processes and tools” – from the Agile Manifesto.
I go from “Good” to “Bad” with two special categories that are discontinuous from the normal scale: “Ideal” and “Evil”. I think of tools as falling somewhere on this scale, but I acknowledge that these tools are evolving products and this diagram may not reflect current reality. The scale looks like this, with a few examples put on the scale:
I still hope that some day someone will build the perfect Agile tool. I’ve seen many of the ideal features listed above in other innovative non-Agile tools. For example, 3M made a PostIt® Plus tool for the iPhone that does some really cool stuff. There’s other tools that do handwriting recognition, etc. Putting it all together in a super-user-friendly package would really get me excited.
Let me know if you think you know of a tool that gets close to the ideal – I would be happy to check it out and provide feedback / commentary!
Title inspired by Michael James…see below.
One of the most powerful assumptions built in to Agile methods is that we learn by doing — that our learning, our planning, our problem-solving, and ability to mitigate risk is enhanced when planning is performed inline with active development and in the context of deliberate experimentation. Scrum, for example, is based on empirical process control theory which means that we make decisions based on what is known.
One of the most common pitfalls we see among organizations trying to “adopt” Agile is excessive pre-planning — their assumption being that we can decide by planning, learn by planning, or mitigate risk by planning. This sometimes manifests as an anti-pattern that people call “Sprint Zero” — a signal that an organization misunderstands Agile methods fundamentally. More importantly, a signal that the organization may incorrectly perceive Software Engineering — or any team-based work — as predictable and repetitive rather than the complex, creative endeavor that it is.
If your organization injects a “Sprint Zero” or a planning phase (that is measured in weeks rather than days or hours) ahead of the creation/development of real product, then these two posts are of interest to you:
For many years, folks in the Agile community have been recommending that performance reviews be eliminated from the corporate world. In 2005 while coaching at Capital One, I remember many discussions on the awfulness of performance reviews. This was really my first understanding of the depth of culture change required to be Agile.
Now, this concept of eliminating performance reviews is gaining traction outside the Agile environment. Here is a great LinkedIn Pulse post by Liz Ryan in which she explains in depth about killing performance reviews.
From her article:
A little voice in the back of my brain nagged at me: “Despite your efforts to make them more compassionate and less uncomfortable for everyone, performance reviews are stupid from the get-go, Liz!
“How does one human being get to evaluate another one, when their personalities and perspectives may be radically different?
Consider using other techniques to help with improvement efforts among your staff. Lean has Kaizen. Agile has Retrospectives.
Real Agility means that learning is inherent in the culture of an organization. Performance reviews establish extrinsic motivators for learning… and all the research points to the idea that learning is much more powerful when it is intrinsically motivated.
Consider some other tools that might help your team to work more effectively, while maintaining intrinsic motivation:
Finally, consider that, at least in Scrum, the concept of a self-organizing, self-managing team makes it very difficult to do performance reviews. It is hard to apportion “blame” or “praise” to individuals. Each team member is dynamically deciding what to do based on the needs of the team, their own skills, and their interest. Team members are often collaborating to solve problems and get work done. Traditional roles with complex RACI definitions are melted away. Performance reviews are very difficult under these circumstances.