Do You “Really” Know Your Team? How to “Turbocharge” Interactions

Have you ever stated, “I didn’t know you could do that?” If so, you were not only stating the obvious, but also exposing a flaw in team formation. What would the result have been if you had known this characteristic about your teammate earlier?

Agile recognizes that people are unique individuals, instead of replaceable resources, and the highest value is achieved through interactions. People have unique physiognomies, however there are also internal characteristics such as motivational gifts, natural talents, learned skills, developmental environment, and personal passion, which can provide a much richer team experience.

Discovering these individual talents and sharing them at the team level can turbocharge interactions and lead to higher productivity. Here is an activity I have used with many people which is designed to expose these characteristics and facilitate better conversations.

Create a Personal Purpose Profile (PPP)

PPPStarting at the Individual level, each person creates a Personal Purpose Profile (PPP) or triple P. The triple P helps people understand their uniqueness in light of the five areas of focus. Each area reveals a different aspect of individuality and presents opportunities to connect with people.

Write PPP at the top of a paper and get ready to create a deliverable which will be a panoramic look at your life. It can be text-oriented or graphical, black and white or more colorful.

Motivational Gifts
PresentThe first area is to determine your motivational gifts. This will help develop understanding and relevant perspectives as a foundation for interaction.

In researching how people communicate and collaborate over 25 years, there are 7 responses or motivations that are regularly displayed during events, scenarios, or interactions. In addition, these reactions show up in people from an early age more like a gift rather than learned behavior.

Each person will typically have one main motivational gift, but can demonstrate some or all of the 7 gifts outlined below. This helps answer “Why don’t others see things the way I see them?” Here is a working definition – an individual’s first reaction when presented with an event, scenario, or interaction.

The 7 gifts and brief definitions are as follows:

  • The Perceiver sees life as all or nothing, right or wrong, and there is no gray area.
  • The Servant seeks to help with any situation.
  • The Teacher desires to share learned information.
  • The Encourager wants to give courage to people.
  • The Giver looks to invest time, talent, and money.
  • The Ruler understands the big picture and needs to control it.
  • The Compassionate is sympathetic to people’s issues.

Do any of these sound familiar? Take a few minutes to examine these gifts and make a few notes, drawings, or doodles on the paper, which identifies your top motivational gifts.

Natural TalentsTalent

The next portion of the triple P is natural talents. These are talents that have been a part of you for as long as you can remember. For example, some people are talented in a form of the arts like drawing, dancing, singing. Others might have outstanding academic aptitude in math or science, etc.   Others may have outstanding athletic ability in a sport. Statements like “you are a natural” or “this comes easy for me” will help to illuminate these as you think about them.

Take a few minutes to continue your triple P by documenting any of your natural talents.

SkillsLearned Skills

Next, is the area of learned skills. During life, there are many opportunities to gain knowledge and occasionally these will develop into valuable learned skills. Examples of these are computer skills, language skills, team skills, and even agile skills. Skills can be learned formally or informally and validated by degrees, certifications, or accreditations. Learned skills might listed on a resume or CV.

List your learned skills on your triple P.

Developmental EnvironmentGlobe

Each person was born and raised in a particular part of the world with it’s own culture, language, food, clothing, and overall lifestyle. These make up a developmental environment. Although it might not be where you are living today, the background will potentially influence your interactions with others.

Look back into your past and write down some of the things that describe your developmental environment.

HeartPersonal Passion

In our busy world, there are many activities that consume time. Most of these are “need to” type scenarios, however somewhere in the 3D arrangement of life is a personal passion waiting patiently to be done.

This could be called a hobby or form of relaxation. However it will usually be related to the question: What would you do if could do anything in the world? Examples could be spending time with pets, athletics, social endeavors, kids, community, etc., etc., etc.

Now that you are dreaming of doing it, draw a picture or write a story about your personal passion on your triple P.

Share Your Uniqueness

Celebrate how unique you are and start sharing your triple P. Don’t wait for someone to say, “I didn’t know you could do that?”  Start with your co-workers and begin to recognize the benefits of knowing your team better. With each passing day, there are interactions that could be improved if the participants knew more background information. It’s amazing how the smallest piece of information can spark a large conversation leading to enhanced communication and collaboration.

TurbochargeHuddle

Agile recognizes that people are unique individuals, instead of replaceable resources, and the highest value is achieved through interactions. Creating and sharing a Personal Purpose Profile (PPP) containing motivational gifts, natural talents, learned skills, developmental environment, and personal passion should be a part of your agile transformation activities.

It’s time to have a team meeting and turbocharge your interactions.

Find out how VersionOne can support your turbocharged teams. 

versionone-coaches-kelly-keyAbout the Author
Kelly Key
SAFe Agilist, PSM1, MOL, PSD

Kelly has more than 25 years of experience in the software industry and 19 years working with agile practices. As an agile program manager, ScrumMaster, agile coach, and VersionOne administrator, Kelly has helped create successful products in the desktop, dot com, and mobile space for the airline, hotel, rental car, rail and cruise industries. As a thought leader, he is always looking to refine processes with continuous improvement while stimulating innovation.

 

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile Teams, Agile Training | Leave a comment

ScrumMaster: Servant Leader or Secretary?

SecretaryIn Certified ScrumMaster (CSM) courses, many Scrum myths are busted. One such myth is that the ScrumMaster is somehow an administrative assistant to a development team, to a product owner or to an organization.

The Scrum Guide notes that the ScrumMaster is the servant leader to a development team, to the product owner and to the organization: http://scrumguides.org/

The guide describes this service as coaching, guiding, enabling understanding, enabling outcomes and so on. It does not talk about the ScrumMaster typing or writing.

Get Your Hands Off the Team’s Work

When ScrumMasters describe writing down “notes” for the team or scribing the team’s tasks at sprint planning this is what I advise ScrumMasterss everywhere: “Get your hands off of the team’s work!”

Will the team ever learn accountability and collective ownership if there’s an admin who will simply scribe everything for them? What will the team do if their ScrumMaster / Secretary is off for the day? Typically nothing is noted in these situations because the team has not assumed any level of accountability or ownership for tracking their own work.

I have the pleasure of working with high performing Scrum teams. Rarely is there a case where the team members expected someone to write down what they were saying or doing. The development team members make notes, type and do all that is necessary. They see it as just “work they have to do,” as opposed to falling into dogma from traditional system development lifecycle roles. The ScrumMasters serving in those situations, truly understand that they are focusing on the outcome, listening for impediments and pulling interactions back on track. When ScrumMasters feel like they have to “scribe,” their focus is split and they rarely pick up on the items that a great ScrumMaster notice.

Get Your Hands Off the Product Owner’s Work

A great ScrumMaster also needs to serve the product owner. I recently performed an assessment in which the ScrumMaster “kept” the product backlog. The product owner had not only never touched the product backlog, they did not even have access to it. Yikes! Once again ScrumMasters who are falling into this dysfunction, I advise:“Get your hands off of your product owners work!”

The product backlog is for the product owner. It is the way they manage the work that is needed for the product. While anyone can add items, this should not be interpreted as “just send your items to the ScrumMaster and they will take care of adding them to the product backlog.” Many dysfunctions are created out of this type of activity. Not only is the product owner not taking responsibility for the list of items to work on for the product, they are also more than likely are not actively refining and getting items to a state of ready by sprint planning time either.

Service to the Organization

Many associate the ScrumMaster with only a development team and a product owner. This tells me that these ScrumMasters are missing a third of the job. The ScrumMaster has responsibilities in the organization to teach, coach and guide the right outcomes.

In Certified Scrum Product Owner (CSPO) classes, I hear product owners describe interactions with steering committees or leaders that get heated, go down rat holes and never have a definitive outcome. “Where was your ScrumMaster when this was going on?” I ask. They go on to explain that no note taking was necessary so the ScrumMaster was probably not needed for the meeting.

The ScrumMaster is a neutral. They are a facilitator. Who better to come along when the product owner expects emotional discussions? As a skilled, neutral facilitator, a great ScrumMaster can keep the discussion fact-based and focus on the outcomes. If good ideas are generated during the discussion, he or she can suggest that these ideas be captured in the product backlog, so that ideas that can be discussed at a later time and don’t detract from the focus of the conversation at hand.

Conclusion

The ScrumMaster is not an administrative assistant or a secretary. They are the master of the Scrum framework. A process enabler. An advocate for the development team, the product owner and the organization. Great ScrumMasters who focus on servant leadership and outcomes will enable delivering of business value with each sprint.

Check out VersionOne’s upcoming CSM and CSPO training classes.

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Project Management, Agile Training, Scrum Development, Scrum Methodology, Uncategorized | 3 Comments

How the Words You Use Affect Your Team

Words have a huge impact on team members affecting their work and ultimately your project, yet we often don’t put much thought into the words we use every day.

Check out some of the positive and negative connotations of traditional and agile project management words.

Waterfall Words vs. Agile Words

I recently went to my colleague Matt Badgley’s presentation Words Mean Things. It made me think about the words that we use in agile and how different they are than the words we used in Waterfall project management. So I compiled a list of words we use every day in project management and compared the waterfall words versus the agile words.

Scope Creep vs. Responding to Change

Scope Creep

 

 

 

 

 

 

 

 

Creep – verb

  1. Move slowly and carefully, especially in order to avoid being heard or noticed.
  2. (Of an unwanted and negative characteristic or fact) occur or develop gradually and almost imperceptibly.

Responding to Change

 

 

 

 

 

 

 

 

Respond – verb

  1. Say something in reply.

Scope creep in waterfall has such a negative feel. The word creep brings images of vines slowly engulfing your project. It makes the business analyst and customer the bad guys trying to sneak extra requirements into the project.

Where in agile, the Agile Manifesto says we should respond to change. Responding is proactively reacting to feedback from our customers. We’re responding to help the business and customer.

Post Mortem vs. Retrospective

Post Mortem

 

 

 

 

 

 

 

 

post•mor•tem

noun

  1. an examination of a dead body to determine the cause of death.

Retrospective

 

 

 

 

 

 

 

 

ret•ro•spect

noun

  1. a survey or review of a past course of events or period of time.

Traditionally you don’t do a post mortem until the end of the project; six months, nine months, or maybe a year. Typically this focuses on what went wrong and the root causes, no one changes their behavior because it’s too late.

Whereas retrospectives are held on a regular basis. We’re reflecting on how things are going in small chunks so we’re able to address issues early before they become a bad habit.

Meetings vs. Ceremonies

Meeting

 

 

 

 

 

 

 

 

meet•ing

noun

  1. an assembly of people, especially the members of a society or committee, for discussion or entertainment.
  2. a coming together of two or more people, by chance or arrangement.

Ceremony

 

 

 

 

 

 

 

 

cer•e•mo•ny

noun

  1. a formal religious or public occasion, typically one celebrating a particular event or anniversary.
  2. the ritual observances and procedures performed at grand and formal occasions.

Most people, especially developers, don’t want to go to a meeting. It feels like a waste of time.

Whereas the word ceremony brings to mind a celebration. People coming together to celebrate something. With Scrum we’re on a regular cadence, working as a team to review the product backlog, commitments and demos.

Requirements vs. User Stories

Requirement

 

 

 

 

 

 

 

 

re•quire•ment

noun

  1. a thing that is needed or wanted.
  2. a thing that is compulsory; a necessary condition.

User Stories

 

 

 

 

 

 

 

 

sto•ry

noun

  1. an account of imaginary or real people and events told for entertainment.
  2. an account of past events in someone’s life or in the evolution of something.

Requirements gives the sense that the discussion is over and you are required to do what has been set. It’s something that’s forced and you don’t have a choice, you have to do it.

Whereas with user stories, since the word user is in that phrase, it is pointing out that you are focusing on the user’s perspective. Then the story is about how that user is interacting with your product, what their pain points are with the product, and what you can do to make it better.

Conclusion

Agile words tend to have a much more positive connotation than waterfall words. This can greatly impact the mood of the team and be another factor to help your projects be more successful. More importantly, I think it shows how words we use every day without thinking can have a significant impact.

What other project management words are more positive in agile?

versionone-coaches-susan-evansAbout the Author
Susan Evans
SAFe Agilist, CSP, CSM, PMP, PMI-ACP

Susan has more than eight years of agile project management experience in software development. Prior to joining the company, she was an internal coach who optimized the usage of the VersionOne platform to help many non-collocated teams thrive in their agile processes. Susan focuses on enhancing team relationships, communication skills, conflict resolution, and processes to help create happy teams that deliver high quality.

Posted in Agile Adoption, Agile Benefits, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 2 Comments

Is Extreme Programming No Longer Relevant?

Agile Methodology UsedExtreme programming is no longer relevant. According to the latest annual State of Agile™ survey, less than 1% of the nearly 4,000 respondents stated that they were practicing Extreme Programming, while 94% said they were practicing agile.

Could it be that the need for engineering practices have passed?

I’m not suggesting that I think that teams don’t need engineering practices, I’m saying that after seeing these stats that I was concerned that people may have stopped thinking that they need engineering practices.

Has the need for engineering practices passed?

Extreme Programming is the first of the big movements that got the attention of the development community. Scrum probably came earlier but it was Extreme Programming that really started igniting people’s imaginations. Yet, lately we don’t hear about it. It made me nervous that agile has had so much momentum, yet the foundational engineering practices seem to have been passed by, so I dug a little deeper.

What I started to uncover is that while Scrum is still the most common project management oriented piece of agile, you’ll notice a lot of organizations are using a hybrid, they’re doing Scrum for their project management and their teams are using Extreme Programming practices without necessarily realizing those practices come from Extreme Programming. I think that’s okay, but it makes me wonder if we might start losing some of those engineering practices because we’re just not talking about them enough.

Extreme Programming Today

First, let’s talk about what is Extreme Programming. Extreme Programming is a set of practices, mostly technical practices, that we want to apply to our software development cycles. Now this can fit nicely with Scrum, so that’s good. Most of these practices are around test-driven development, which is vital. Practices such as refactoring, continuous refactoring, continuous integration, automated acceptance tests and pair programming. There are others, but these are the ones that I see as the heart of Extreme Programming. If we want to continue to emphasis these practices without calling them Extreme Programming, we might start to lose the holistic nature of what XP is all about. So I do worry about that.

I take heart that Extreme Programming practices are being used somewhat unconsciously. Often when I meet a new team practicing Scrum and ask about technical practices, they look at me like I’m crazy and say, “Well, duh, of course we are doing that.” That’s fantastic, but with the dramatic growth of Agile in the enterprise we need to be careful that we don’t start to lose these practices.

This makes me think of something Kent Beck said at the very first Extreme Programming Universe Conference, “You know, five years from now I hope we don’t even use the name, XP. It’s just how people make software.” It seems he has gotten at least half of his wish, people don’t tend to use the name, XP, but I’m not sure we’ve gotten to the point where it’s just how we write software.

Enterprise agile is, by necessity, going to focus more on project, program and portfolio management, leaving the implementation to the teams themselves. If no one is talking about technical practices, may they one day be overlooked and forgotten?

From my perspective, what we really need to do most is build on agile’s momentum by digging deeper into the technical practices. We need to make the second half of Kent Beck’s wish come true and make technical practices just how we write software.

A consultant by the name of Payson Hall once made a comment that sticks with me, “If you can’t reach this distance, you’re not tall enough to ride this ride.” If you’re not doing the Extreme Programming practices: pair programming, refactoring and so on, then you’re not ready to get on the agile ride. It doesn’t matter how many iterations you plan, how many fantastic meetings you have, how many Scrum gatherings you attend, if you’re not doing the engineering practices, you’re not going to be as successful as you could be.

As often is the case, this is not just a technical problem, it’s a people problem. If the organization feels like they are agile just because they are doing sprints or have a kanban board, they’re not where they need to be. They’re not going to succeed. They might get some traction. It’s certainly going to be better than just waterfall but they’re still not there. The whole point behind Agile practices is we need to reduce and flatten the cost of change curve and we can only do that with the technical practices in place.

What’s Next for Technical Practices?

There’s another movement that has been growing over the past few years called Software Craftsmanship. If you look closely, if you scratch the surface of the Software Craftsmanship movement, what you’ll see is the same people who have been incredibly active in the Extreme Programming community. This is no accident.

The Software Craftsmanship movement is a reaction to the emphasis on project management and a way to bring Extreme Programming practices and the idea that creating software is more than just typing a bunch of lines of code into. It’s important that we look at Software Craftsmanship as a natural extension of Extreme Programming.

We need to keep focus on the foundational principles that are core to XP, not just the technical practices but the values: communication, feedback, courage and, simplicity. Those values being an important part of our day-to-day lives in the software development community. Craftsmanship is a nice wrapper; it gives us a metaphor to think about it where Extreme Programming gives us the actual activities and the values that can help us make that successful.

Conclusion

What’s next for Extreme Programming? What can you do about this?

First, go read the book again. Every couple of years I go back and read the book and I learn more. It reminds me why this was so exciting in the first place. Second, make sure you’re doing these things. Make sure you’re embracing these values and practicing the technical practices on a day-to-day basis.

Does that mean that we’ll bring the words, Extreme Programming, back to the front? I don’t know. I don’t know if I care. What I do care about is that we find a way to get these great ideas back into the software development world.


versionone-coaches-steve-ropaSteve Ropa

CSM, CSPO, Innovation Games Facilitator, SA
Agile Coach and Product Consultant, VersionOne

Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Posted in Agile Project Management, Extreme Programming, Uncategorized | 2 Comments

7 Tips We Learned About SAFe from Dean Leffingwell

SAFe is a marathon, not a sprint, and it can sometimes be fairly challenging, so who better to provide some tips than Dean Leffingwell, the creator of the Scaled Agile Framework® (SAFe®).

Here are seven tips I learned from the recent AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.”

In addition, there were more questions than we had time to answer during the live event. I’ve attached the Q&A here.

7 Tips We Learned about SAFe from Dean Leffingwell

1) We need a new approach, one that harnesses the power of lean and agile and applies to the needs of those building complex applications and systems.

The Agile Manifesto was developed for small teams, but it also applies really well to organizations that have scaled horizontally rather than vertically. There is an entire body of work on lean now, with dozens of books written by Don Reinertsen, Michael Kennedy, Alan Ward and others that are great books, but they’re mostly ethereal principles, not practice-based. When I think about SAFe, I think about codifying the things we’ve learned and turning those principles into practices.

2) This cannot be a bottoms-up movement that falls on the deaf ears of leaders and managers.

Management owns the system and is responsible for changing it. Lean and SAFe are leadership approaches. That’s an important statement about where the responsibility lies.

3) One of our bedrocks is the house of Lean. The house of Lean transcends the team. It’s a value system that’s very broad and has value at the top. It has pillars and it has leadership.

The SAFe Value System is drawn as a house for a reason. Value is most easily stated as achieving the sustainably shortest lead time with best quality and value to people and society. How do you make that work? One of the pillars is ”respect for people and culture.” We must understand that a change to an enterprise is a change to culture and a change to people.

4) Product development flow is a key part of what we described, as well as how to avoid the stop, start, stop, start, milestone, stop, post-milestone, start activity to deliver value continually.

Innovation: we have a brand new body of work from the lean startup community furthering relentless improvement, or the Kaizen mindset. Kaizen is a change word; it’s a word designed to get people’s attention and make them ask, “You say you are continuously improving, but are you relentless in that improvement? Tell me one problem you’re working on right now and tell me what tools you’re using to solve the problem.”

5) At the enterprise-level we’re literally scaling agile across the enterprise. We need leadership. It’s not optional.

The foundation of agile development is agile teams. We’re scaling agile, so we can’t treat the leaders as impediments or just pretend as though we taught the software development teams to speak Chinese and we didn’t bother to teach the leaders. That’s not going to scale.

6) If you’re talking about enterprise-level problems, you must apply systems thinking.

Optimizing a part does not optimize the whole. Only when you optimize the whole do you get the optimum result. Build incrementally with fast, integrated learning cycles. That’s the PDCA loop of Walter Shewhart and W. Edwards Deming; that’s what an iteration is.

7) We want the measures to be meaningful.

SAFe is focused on milestones that are based on objective evaluation of working systems. Measurements that help visualize, limit WIP, reduce batch size and manage queue lengths are the basic tenets of flow. A long queue of work means you’re slow and a long queue of committed work means that you’re predictably slow. Shorten the queue and you’re going to get faster. You don’t have to just cut code faster to get results faster; you just need to manage the queue.

Conclusion

I hope you found these tips as beneficial. As I said in the beginning, SAFe is a marathon, not a sprint. If you find yourself in a bind, don’t stress; someone has probably encountered a similar challenge and can provide a few helpful tips.

Interested in learning more? Watch to the recording of the AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.”

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in Agile Development, Agile Project Management, scaled agile, scaled agile framewok, Scaling Agile | 1 Comment

10 Agile Books You Should Read This Summer

It’s all too easy to take it a little bit easier during the summer, so we created a list of agile books to keep you on your toes.

Whether you read them at the beach on vacation or the back porch while the kids are at camp, you can rest assured that your agile practice will be a little bit better this fall.

Sutherland bookScrum: The Art of Doing Twice the Work in Half the Time
By Jeff Sutherland

We live in a world that is broken. For those who believe that there must be a more efficient way for people to get things done, here from Scrum pioneer Jeff Sutherland is a brilliantly discursive, thought-provoking book about the management process that is changing the way we live.

In this book you’ll journey to Scrum’s front lines where Jeff’s system of deep accountability, team interaction, and constant iterative improvement is, among other feats, bringing the FBI into the 21st century, perfecting the design of an affordable 140 mile per hour/100 mile per gallon car, helping NPR report fast-moving action in the Middle East, changing the way pharmacists interact with patients, reducing poverty in the Third World, and even helping people plan their weddings and accomplish weekend chores.

Woven with insights from martial arts, judicial decision making, advanced aerial combat, robotics, and many other disciplines, Scrum is consistently riveting. But the most important reason to read this book is that it may just help you achieve what others consider unachievable – whether it be inventing a trailblazing technology, devising a new system of education, pioneering a way to feed the hungry, or, closer to home, a building a foundation for your family to thrive and prosper.

*Book description from Amazon

Cobb bookThe Project Manager’s Guide to Mastering Agile:
Principles and Practices for an Adaptive Approach

By Charles G. Cobb

The Project Management Profession is beginning to go through rapid and profound transformation due to the widespread adoption of agile methodologies. Those changes are likely to dramatically change the role of project managers in many environments as we have known them and raise the bar for the entire project management profession; however, we are in the early stages of that transformation and there is a lot of confusion about the impact it has on project managers:

  • There are many stereotypes and misconceptions that exist about both Agile and traditional plan-driven project management
  • Agile and traditional project management principles and practices are treated as separate and independent domains of knowledge with little or no integration between the two and sometimes seen as in conflict with each other
  • Agile and “Waterfall” are thought of as two binary, mutually-exclusive choices and companies sometimes try to force-fit their business and projects to one of those extremes when the right solution is to fit the approach to the project

It’s no wonder that many Project Managers might be confused by all of this! This book will help project managers unravel a lot of the confusion that exists; develop a totally new perspective to see Agile and traditional plan-driven project management principles and practices in a new light as complementary to each other rather than competitive; and learn to develop an adaptive approach to blend those principles and practices together in the right proportions to fit any situation.

*Book description from Amazon

Scaled Agile Framework (SAFe) Distilled:
A Practical Guide to Scaling Agile in the Enterprise
By Richard Knaster and Dean Leffingwell

Today, companies know they must adapt quickly or die. They are increasingly seeking to adapt by using agile principles and practices – but many are still changing too slowly, and can’t sustain change. Fortunately, a growing number of enterprises have found a far more effective solution: the Scaled Agile Framework (SAFe).

SAFe changes the game by integrating Agile, Lean and product development flow thinking with a new operating model that successfully coordinate works at all levels: team, program, and portfolio. SAFe helps managers learn to become lean-thinking leaders, working with teams to continuously improve their systems, and create environments where everyone flourishes.

In Scaled Agile Framework (SAFe) Distilled, two SAFe pioneers show software practitioners how to use achieve higher productivity, improve the quality of their software processes, and bridge the divide between executives, managers and practitioners – aligning everyone towards common goals and objectives. If you want to scale and sustain agile in the enterprise, SAFe can get you there. Scaled Agile Framework (SAFe) Distilled will help you launch it, quickly earn value from it, and grow its value with every new project.

*Book description from Amazon

AgileChangeMgtAgile Change Management:
A Practical Framework for Successful Change Planning and Implementation

By Melanie Franklin

The concept of agile working has been adopted by many organizations that recognize the need to respond quickly and easily to new opportunities in a world of complex and continuous change.

Agile Change Management offers best practice advice for planning and implementing change projects. Concrete tools help deliver projects successfully and realize benefits earlier on in the process.

By emphasizing and encouraging collaborative practices, the book illustrates how to build trust, influence and motivate others, and create a roadmap that outlines all the processes, activities and information needed to manage any type of change initiative. With advice for creating the right environment for change the book explains: who should be involved at each stage in the life style cycle, what tasks need to be completed at each stage, the concept of change in both large scale transformational programs and micro-level business projects, and the needs and benefits behind change strategies.

Along with a practical toolkit of materials available both online and in the book, Agile Change Management is essential reading for anyone who wants to develop the competencies of an effective change manager working in any project or program.

*Book description from Amazon

AgileMgt(1)Agile Management for Software Engineering:
Applying the Theory of Constraints for Business Results

By David J. Anderson

This book is certainly about software development management, but it is also a book about business. Managers can no longer afford to discuss these two topics independently. This book is meant to eliminate the seat-of-the-pants intuition and rough approximations that have been far too prevalent in software development management. The growing popularity of agile methods has shown that a healthy balance between strict process and individual flexibility can be achieved.

David Anderson takes it a step farther, and explains how the healthy balance of agility can help businesses become more profitable. The result is a book that will allow managers to foster teams that produce better software, less expensively, on time, and with fewer defects.

*Book description from Amazon

AgileMgtLeadershipAgile Management
By Ángel Medinilla

If you have tried to implement Agile in your organization, you have probably learned a lot about development practices, teamwork, processes and tools, but too little about how to manage such an organization. Yet managerial support is often the biggest impediment to successfully adopting Agile, and limiting your Agile efforts to those of the development teams while doing the same old-style management will dramatically limit the ability of your organization to reach the next Agile level.

Ángel Medinilla will provide you with a comprehensive understanding of what Agile means to an organization and the manager’s role in such an environment, i.e., how to manage, lead and motivate self-organizing teams and how to create an Agile corporate culture. Based on his background as a “veteran” Agile consultant for companies of all sizes, he delivers insights and experiences, points out possible pitfalls, presents practical approaches and possible scenarios, also including detailed suggestions for further reading.

If you are a manager, team leader, evangelist, change agent (or whatever nice title) and if you want to push Agile further in your organization, then this is your book.

*Book description from Amazon

AgileCoachingAgile Coaching Paperback
By Rachel Davies and Liz Sedley

Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices – it’s a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team.

To lead change, you need to expand your toolkit, and this book gives you the tools you need to make the transition from agile practitioner to agile coach.

Agile Coaching is all about working with people to create great agile teams. You’ll learn how to build a team that produces great software and has fun doing it. In the process, you’ll grow a team that’s self-sufficient and skillful.

This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software. You’ll find chapters dedicated to introducing Test-Driven Development, designing retrospectives, and making progress visible.

*Book description from Amazon

AgileEstimatingAgile Estimating and Planning Kindle Edition
By Mike Cohn

Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In this book, Agile Alliance cofounder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.

Concepts are clearly illustrated and readers are guided, step by step, toward how to answer the following questions: What will we build? How big will it be? When must it be done? How much can I really complete by then? You will first learn what makes a good plan-and then what makes it agile.

Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more. Highlights include:

  • Why conventional prescriptive planning fails and why agile planning works
  • How to estimate feature size using story points and ideal days—and when to use each
  • How and when to re-estimate
  • How to prioritize features using both financial and nonfinancial approaches
  • How to split large features into smaller, more manageable ones
  • How to plan iterations and predict your team’s initial rate of progress
  • How to schedule projects that have unusually high uncertainty or schedule-related risk
  • How to estimate projects that will be worked on by multiple teams

*Book description from Amazon

AgileExperience_Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous (Voices That Matter)
By Lindsay Ratcliffe

Agile development methodologies may have started life in IT, but their widespread and continuing adoption means there are many practitioners outside of IT – including designers – who need to change their thinking and adapt their practices. This is the missing book about agile that shows how designers, product managers, and development teams can integrate experience design into lean and agile product development. It equips you with tools, techniques and a framework for designing great experiences using agile methods so you can deliver timely products that are technically feasible, profitable for the business, and desirable from an end-customer perspective.

This book will help you:

  • Successfully integrate your design process on an agile project and feel like part of the agile team
  • Do good design faster by doing just enough, just in time
  • Use design methods from disciplines such as design thinking, customer-centered design, product design, and service design
  • Create successful digital products by considering the needs of the end-customer, the business, and technology
  • Understand the next wave of thinking about continuous design and continuous delivery

*Book description from Amazon

AgileProjMgtAgile Project Management with Scrum (Developer Best Practices)
By Ken Schwaber

The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster.

Gain the foundation in Scrum theory—and practice—you need to:

  • Rein in even the most complex, unwieldy projects
  • Effectively manage unknown or changing product requirements
  • Simplify the chain of command with self-managing development teams
  • Receive clearer specifications—and feedback—from customers
  • Greatly reduce project planning time and required tools
  • Build—and release—products in 30-day cycles so clients get deliverables earlier
  • Avoid missteps by regularly inspecting, reporting on, and fine-tuning projects
  • Support multiple teams working on a large-scale project from many geographic locations
  • Maximize return on investment!

*Book description from Amazon

Whether you’re brand new to agile or been practicing for years, there’s something for everyone on this list of summer agile reading. I hope the list has inspired you to continue your agile advancement this summer.

What other books would you recommend?

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Scrum Development, Scrum Methodology, Uncategorized | 2 Comments

Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives

Satish2

 

 

 

 

 

 

 

In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.

In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.

Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.

Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows.  The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage.  However, the implementation of each objective with specific practices depends on the level.  For each of the four objectives, there are four practices corresponding to four levels of planning.  Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.

Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices

Table1A_V2

Table1B_V2Objective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook:  At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.

Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions:  Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop).  Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence.  Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.

Objective 3 – Develop your agile plan:  At each level of planning, several outputs must be produced to develop the Agile Plan at that level.  Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning.  Note that the agile plan also needs to specify how workflow against the plan will be monitored.

Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis:  An agile plan is not an end-all in itself.  As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning).  The nature and method of re-planning change with the planning level.   The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.

Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.

Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations

Figure 3 shows this relationship along with an explanatory legend.  I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook.  Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1.  Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook.  Four planning level-specific playbooks are part of the Agile Planning Playbook.  Each level of planning provides the context for the next lower level of planning.  Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.

Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook.  As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.

If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook.  Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level.  Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level.  An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes).  This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.

Fig3_APF_APP

Fig4_Legendfor_Fig3Figure 3: Relationship among Agile Planning Framework, Agile Planning Playbooks, Agile Plans and Implementation

Guidelines for customizing the Agile Planning Framework:  For a client-specific project of a relatively modest duration (say, six months), you may be able to skip Level 1 planning (Product Vision and Strategy) and start with Level 2: Release Planning, consisting of two release cycles of three months each.

Teams that are new to agile development may start with Level 3: Sprint planning and Level 4: Daily Planning and Daily Scrums.  As they gain experience of few sprints under their belt, they may then start doing Level 2: Release planning, and with further experience start with Level 1: Product Vision and Strategy planning.

For entrepreneurial start-ups with high degree of uncertainty about their real customers and their real problems, and about technical feasibility of their solution, staring with a two-year long vision and strategy exercise may not be very productive.  A start-up may spend the first several months on Level 3 (Sprints) and Level 4 (Daily) planning and execution to validate their assumptions, demonstrate prototypes to potential customers, and make small changes in the (implicit) strategy or even “pivot” (significantly change) the strategy based on feedback from short sprints.  Only when they have a good understanding about real customers and their real problems, and have some confidence in technical feasibility of their solution, they may advance to Level 2 (Release) and finally to Level 1 (Product Vision and Strategy) planning.

For a very large organization with many portfolios, programs and projects, you may have five levels of planning: Portfolio vision and strategy, Product vision and strategy, Release planning, Sprint planning, and Daily Planning and Daily Scrums.   Alternatively, you may choose to have multiple Agile Planning Books targeted for different lines of businesses or product lines.

For well-jelled, highly experienced and stable teams that have demonstrated a stable velocity pattern (velocity changes within a narrow range across successive sprints), Planning Level 4 can be substantially simplified.  Such teams should still conduct Daily Scrum meetings and may break stories into SMART tasks, but may track the effort for an entire story, and not at the task level.

You may add one or a small number of new objectives (beyond four objectives in Table 1) to your Agile Planning Framework, if required for your specific situation.  Ability to add new planning levels and new objectives makes the Agile Planning Framework extensible.  If you decide to add new levels or new objectives, I will be very interested in knowing the reasons (you may send me an email at Satish.Thatte@VersionOne.com).  If you delete or modify or relax any of these four objectives, your agile plan will be incomplete or inadequate or of poorer quality compared to a plan developed by rigorously and diligently following all four objectives.

From Agile Planning Framework to your customizable agile planning playbook:  Agile champions owning the agile planning playbook have many important responsibilities:

  • Take the Agile Planning Framework from this blog series and customize it to create your agile planning playbook, instead of developing the playbook from scratch. This will save you substantial effort and result into a better and higher-quality playbook.
  • Choose your own method for implementing each of 16 practices of Table 1. Furthermore, you should explore how to integrate your agile planning playbook with your Agile Lifecycle Management platform (see below) as that will make its actual use by agile champions, agile planners and agile team members much more likely and natural.
  • After getting the buy-in and commitment for agile planning from your senior executives, educate agile planners and stakeholders in your organization on the agile planning playbook to be used in your company, and also get their inputs in developing your agile planning playbook.
  • Make sure that your agile planning playbook is followed by agile planners at all four levels of agile planning, and even more importantly agile team members do their work driven by those plans.
  • Improve the agile planning process and the playbook on an on-going basis.

The resulting agile planning playbook can be a brief document or a set of wiki pages.  However, this solution will be disconnected from and will be poorly integrated with your ALM platform, and may not get used much as it is an “out-of-band” solution; and for that reason, it’s not my favorite.  I strongly recommend that you implement and operationalize your agile planning playbook as an “in-band” solution that is well-integrated with your ALM platform.

If you are using or planning to use VersionOne as your ALM platform, I encourage you to implement your agile planning playbook using VersionOne Communities, Templates, Reporting and Customization capabilities, pilot your playbook with few agile projects, and then roll it out at a larger scale.  If you have questions on how to implement and operationalize your customized agile planning playbook or to implement a more comprehensive agile lifecycle playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.

Though last but not the least, the agile planning playbook is necessary but not sufficient for agile success.  Excellence in agile project execution is also essential, in addition to be good at agile planning.  However excellence in execution will not be effective in delivering business results without proper agile planning.

The past blog of this blog series:

  • Blog 1: Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels

The next five blogs of this blog series:  In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.

  • Blog 3: Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
  • Blog 4: Succeed in each Release using Your Agile Release Planning Playbook
  • Blog 5: Succeed in each Sprint using Your Agile Sprint Planning Playbook
  • Blog 6: Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook

In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.

If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.

Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).


versionone-coaches-satish-thatteAbout the Author
Dr. Satish Thatte
SPC, CSM, CSPO, CSP

Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne.  He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level.  He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.

His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute.  Learn more about Satish and his blogs at LinkedIn and blogs.

Posted in Agile Adoption, Agile Coaching, Agile Leadership, Agile Management, Agile Methodologies, Agile Portfolio Management, agile program management, Agile Project Management, Enterprise Agile, scaled agile | Leave a comment

Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels

Satish1

 

 

 

 

 

 

 

Many people know that agile planning is different from big up-front detailed planning done in traditional or waterfall projects.  However, there are many misconceptions or only partial understandings of agile planning.

In this first blog post in a series of six, I will begin to explain the details of agile planning: what and why, and multi-level planning and its benefits.

What is Agile Planning?

Some people equate agile planning with minimal planning or just-in-time planning or “fluid” or “adaptive” planning or planning to be done by the whole team not managers – all these characterizations cover only some aspects of agile planning.  Agile planning is more involved, more disciplined, and rigorous than what some people think.

If done right, agile planning requires modest time and effort. This planning effort should not be viewed as an overhead, or a chore to be done by “agile project managers”. Planning is part of the overall work. If you don’t plan or plan poorly, no amount of execution effort would adequately compensate for poor agile planning. “Winging” an agile plan is expensive and doesn’t work well. As Benjamin Franklin said, “If you fail to plan, you are planning to fail!

The Agile Planning Framework is based on multiple levels of planning – typically four levels – as illustrated in Figure 1.

  • Level 1: Product vision and strategy planning – this is the top level of planning
  • Level 2: Release planning
  • Level 3: Sprint planning
  • Level 4: Daily planning and daily Scrums – this is the bottom level of planning

Figure 1 also illustrates the key goals at each of four planning levels.  Each level of planning is elaborated and supported by the next lower level of planning at smaller planning units, but with greater details (elaboration) and on a shorter planning time horizon, as will be explained soon.  Figure 1 is based on a popular poster from VersionOne that you may download for your use.

Fig1_Planning_Levels

Figure 1: Four Levels of Agile Planning

The Three Agile Planning Roles

Note that these are roles, and not necessarily three distinct sets of people.  Many planners also implement the plan, and many implementers are involved in planning.  In many organizations, the same person may play one or more of these roles. A sprint planner could be a team member doing his/her Daily planning and may also be a release planner. A release planner could also play the role of an agile champion. A software architect could be a team member, sprint planner, release planner, product vision and strategy planner, and agile champion. Each team member is a daily planner and is expected to work and deliver on that daily plan.

1. Agile champions: Agile champions are responsible for implementing, maintaining and improving an organization’s customized agile planning playbook by briefly and effectively documenting the agile planning process at each level as well as evangelizing and teaching the planning process to agile planners. The champions also revise and improve the agile planning playbook based on the feedback from agile planners, agile team members, as well as changing market conditions, competitive response, business conditions, technology changes, etc.

These agile champions are the owners of your agile planning playbook. They may be senior executives or senior managers responsible for your organization’s agile transformation. They could also come from your enterprise’s agile Project Management Office (PMO) or they may be a group of enthusiastic and committed ScrumMasters if the agile initiative is started at the team level.

2. Agile planners: Agile planners are responsible for following the agile planning playbook to conduct planning and do re-planning as is necessary. An agile plan needs to be revised and adjusted at an appropriate frequency (based on the agile planning level) based on the feedback from agile team members, stakeholders, and also from the environment, as explained below. Agile planners work with the appropriate stakeholders to seek their input, guidance and expertise in the planning process.

3. Agile team members: Agile team members are responsible for day-to-day work of developing, delivering, deploying, operationalizing and supporting agile project deliverables after each sprint and release cycle. This day-to-day work is driven by agile plans developed by the planners at each level. These self-organized team members should have cross-functional expertise in areas of analysis, software design, user experience design, code development, testing, technical writing, data center deployment and operations, etc. Note that agile team members are not only daily planners, but also sprint planners; some of them may participate in release planning, and some may be called upon to help in product vision and strategy planning.

The Four Guidelines for Agile Planning

1. Plan and elaborate progressively at each planning level: Planning done at each level is a pre-requisite for the next lower level of planning. It serves as the context and guides planning at the next lower level.  Product vision and strategy planning (Level 1) should proceed in the context of completed planning at the business vision and strategy done by senior C-level executives responsible for overall business; as this planning is related to the overall enterprise business, it is outside in the scope of this blog series.   Without a reasonable business vision and strategy in place, planning product vision and strategy is difficult and ineffective.  Release planning (Level 2) should proceed in the context of completed planning at the Product vision and strategy (Level 1).   Without a reasonable product vision and strategy in place, Release planning is very difficult.   Sprint planning (Level 3) should proceed in the context of completed release planning (Level 2).  Without a reasonable Release plan in place, Sprint planning could be difficult or at best tactical.  Daily planning and daily Scrums (Level 4) should proceed in the context of completed sprint planning (Level 3).  Without a reasonable sprint plan in place, daily planning is not very effective.  It is not advisable to plan at a level and then skip one or two levels to jump to a lower level; for example, starting at planning level 1, skipping Level 2, and jumping to Level 3 should be avoided.

2. Choose proper planning horizon, and granularity of planning and workflow monitoring at each level of planning: Planning time horizon should start with a typical 1 to 3 year range at Level 1 (product vision and strategy) and should shrink to a single workday at Level 4 (daily planning and daily Scrum). As planning time horizon shrinks, the granularity for planning and workflow monitoring should also shrink from “very large” (at Level 1) to “very small” (at Level 4).

Level 1 – Product vision and strategy planning: Large to very large planning and workflow monitoring units, such as product goals and initiatives, strategic themes. These units are typically modeled as initiative epics and may take several months or release cycles to complete.

Level 2 – Release planning: Moderate planning and workflow monitoring units, typically modelled as feature epics that can be completed in a single release cycle consisting of multiple sprints.

Level 3 – Sprint planning: Small planning and workflow monitoring units, such as user stories and other work items (defects, spikes, regression test cases, etc.) that can be completed in a single sprint.

Level 4: Daily planning and daily Scrum: Very small planning and workflow monitoring units which are SMART tasks that implement a story or a work item. A SMART task is completed typically in four hours or less in a single workday.  Acronym SMART stands for: S: Small, M: Measurable, A: Achievable, R: Realistic and T: Time-bound

With longer time horizon, it makes sense to plan and monitor workflow at larger granularity of work. When planning horizon is long-term (Level 1 planning), working on small or medium-grain planning units (stories and epics) makes little sense as those small work items usually are not even known during Level 1 planning, and it would be a wasteful practice as many small work items will almost certainly change over time even if we spend effort to identify and model them during Level 1 planning.

3. Identify proper agile planners and stakeholders that must work together with commitment to required planning preparation and allocation of required planning time: Agile champions in your organization should identify the right planners and appropriate stakeholders at each level of planning, and those agile planners must work with the right stakeholders effectively. Agile planners must be well prepared and committed to attend all planning meetings and workshops with their quality time and focus without interruptions.  This often requires a cultural change in many organizations, and may need executive support and sustenance.  This also requires training of agile planners and stakeholders, and guidance by qualified coaches to conduct agile planning workshops at each level of planning.

Product vision and strategy planners and their planning time: Executives work with Product manager and other appropriate stakeholders. Three to nine days of total planning effort is typically required depending on the product size, duration and complexity for a one to three year product horizon (240 workdays per year).  A product vision and strategy plan should be revised or fine-tuned at the end of each release cycle.  If you consider additional two to five days of effort to prepare for planning (Practice 1.2), and two to five days of effort to revise and maintain the Product Vision and Strategy Plan, it still amounts to only 3% of total time for planners at this planning level.

Release planners and their planning time: Release manager, product owner, ScrumMaster and team leads work with managers and representatives of other related release teams (for large projects). Two to four days of planning effort is typically required for a three to six months release cycle (22 workdays per month).  A release plan should be revised at the end of each sprint cycle.   If you consider additional 0.5 to 1 day of effort to maintain and revise the release plan, it still amounts to a very modest 4% of total time for planners at this level of planning.

Sprint planners and their planning time: The whole team (all its members) does planning and works with managers and representatives of other related teams (for large project). Four to eight hours of planning effort is typically required for a two- to four-week sprint (five workdays per week). This amounts to a modest 5% of total time for planners at this level of planning.

Daily planners and time for planning and attending Daily Scrums: Each team member plans his/her individual daily work, typically requiring 10 minutes of daily personal work planning effort.  This planning must be completed prior to each daily Scrum meeting which takes another “2n+5” minutes, where “n” is the number of team members in a team (see my blog series on how to make Daily Scrums Effective and Efficient); it takes two minutes for each team member to present his/her daily work plan and to report against the plan of the previous workday (tasks done or not done), and another five minutes for the team to review key metric such as the burn-down and burn-up reports.  Thus it takes 15 to 23 minutes per day (depending on the size of the team ranging from 5 to 9 cross-functional, self-organized team members) to conduct the daily Scrum meetings.  The total time to prepare the daily plan and attend the daily Scrum is 25 to 33 minutes.  This amounts to a modest 5% to 7% of total time for each team member.

In future blogs of this blog series, I will present the details of the recommended schedule and cadence for the planning sessions at all four planning levels.

4. Define workflows at each level of planning and execution:

Each higher level of planning sets the context and drives the work at lower levels of planning as illustrated in Figure 2.  Agile planners must define the workflow at each level of planning.  As shown in Figure 2, at Product Vision and Strategy planning level, work items are modeled as Initiative epics and they flow in sequential stages: Approve and Fund, Implement, Deployed, and Measure Return on Investment (ROI).   As an Initiative epic reaches Implement status, it signals that work can be initiated at the next lower level, i.e., Release planning level.  An Initiative epic gives rise to many Feature epics at the Release planning level; when a feature epic is broken down into stories and reaches the Build status, it signals that work can be initiated at the Sprint planning level.  When a user story reaches Development status in a sprint, its SMART tasks are pulled by individual team members to work on and their workflow is monitored on the Taskboard as part of Daily workflow.  When all tasks for a story are completed, the story is Accepted by Product Owner (assuming it passes all its acceptances tests), and gets Deployed.  When all stories for a Feature epic are Deployed, that Feature epic moves to Deployed status on Feature Epicboard.  When all Feature epics of an Initiative epic are Deployed, the Initiative epic moves to Deployed status on the Initiative Epicboard.

Agile planners need to define policies for managing workflows at each level (rules for status transitions); and board-level policies, such as Work-in-Process (WIP) limits, cycle time thresholds, etc.   There is plenty of opportunities to customize the workflows, status columns, and policies at each level of planning.   I will explain the workflow at all four planning level in four future blogs of this blog series.Fig2V4_Workflows

Figure 2: Customizable Workflows at Each Agile Planning Level

Agile Planning Playbook

As my colleague Mike McLaughlin explained in his agile playbook blog, an agile playbook is a helpful guide that briefly documents your agile process. I believe an agile lifecycle playbook should cover the entire value stream from product vision, strategy, analysis, design, development, testing, delivery, deployment, operations, support, and customer value realization. These are not sequential phases of work; often agile team members “swarm” to do many tasks concurrently and in close harmony, such as analysis, design, development, testing; and even deployment and operations as the DevOps movement proposes.

An agile lifecycle playbook helps ensure consistency among projects and teams, improves their productivity and quality of work and reduces mistakes and errors. VersionOne’s 9th Annual State of Agile™ survey has indicated that the consistent process and practices is the top tip for success in scaling agile.    You can and should start using your agile lifecycle playbook even with single teams and smaller projects to ensure consistency across successive sprints, and improve your playbook with on-going experience.

An agile planning playbook focuses on agile planning aspects of the agile lifecycle, and is a part of the overall agile lifecycle playbook for your organization. Your agile planning playbook facilitates agile planning in a standard and consistent way across the whole enterprise or at least across a set of common projects or teams. There is no “one size fits all” agile planning playbook that suits all organizations.

Consider these very different types of organizations.

  • A relatively small company working on its next product over multiple release cycles with four agile teams consisting of a total of 35 members
  • A large bank with portfolios of many projects consisting of 1,200 project members and developing software for in-house use
  • An organization developing and operating a large e-Commerce service through Internet cloud
  • A Department of Defense contractor developing a mission-critical system (hardware and embedded software) spanning five years of development cycle

Each organization, product, program or project, as well as teams and people and their practices, history and cultures are unique.  Therefore each organization or a division or a line of business will need a customized agile lifecycle playbook and agile planning playbook to serve its unique needs and business goals. However, agile planning needs of diverse organizations share a common core based on agile principles, values, and agile framework.

The Agile Planning Framework is based on a common core of agile planning principles and practices.  The framework is common for all organizations interested in agile development. Your organization can develop one or more agile planning playbooks from the common framework by customizing and implementing it in ways that best serves your needs.

Most of the material in this blog series is written with a focus on the lifecycle of software products or services or embedded software products that are intended for multiple customers in their chosen market segment.  With appropriate modifications, you can use this framework for a number of different situations, such as:

  • Single client-specific custom software project
  • An entrepreneurial start-up company with a lot of uncertainty
  • Scaled agile environments where there may be many portfolios of programs and projects

I will explain how you can modify the Agile Planning Framework to suit these different situations throughout this blog series.

The next five blogs of this blog series: In the next blog (Blog 2 of this series), I will explain four objectives at each planning level of the Agile Planning Framework.   In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.

  • Blog 3: Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
  • Blog 4: Succeed in each Release using Your Agile Release Planning Playbook
  • Blog 5: Succeed in each Sprint using Your Agile Sprint Planning Playbook
  • Blog 6: Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook

In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.

Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).


versionone-coaches-satish-thatteAbout the Author

Dr. Satish Thatte
SPC, CSM, CSPO, CSP

Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne. He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level. He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.

His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute. Learn more about Satish and his blogs at LinkedIn and blogs.

Posted in Agile Benefits, Agile Coaching, Agile Leadership, Agile Methodologies, Agile Portfolio Management, agile program management, Agile Project Management | 1 Comment

10 Agile Quotes From The World’s Most Brilliant Minds

Truly embracing agile can be a very hard task; agile practices are mostly learned and experienced, not something that you can easily glean from a book or article. But if you’re in search for valuable agile quotes to inspire you and your teams, here are 10 from the world’s most brilliant minds.

Brilliant Agile Quotes

Einstein

 

 

 

 

 

 

 

 

1) “Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”
– Albert Einstein

As agile organizations, teams and team members, we must constantly question what could be better in order to continually improve.

Lombardi

 

 

 

 

 

 

 

 

2) “Perfection is not attainable, but if we chase perfection we can catch excellence.”
-Vince Lombardi

Perfection is a fallacy that leads to over planning, procrastination and failure to ship; agile is about focusing on delivering the best thing possible in a set time period.

Suess

 

 

 

 

 

 

 

3) “Unless someone like you cares a whole awful lot, nothing is going to get better.
It’s not.”
– Dr. Seuss

Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization, so that you can care to make things better.

Ali

 

 

 

 

 

 

 

 

4) “Service to others is the rent you pay for your room here on earth.”
– Muhammad Ali

Service leadership and selflessness are foundation principles of agile; these are the prices to be paid to be part of an agile team.

Lucas

 

 

 

 

 

 

 

 

5) “You simply have to put one foot in front of the other and keep going. Put blinders on and plow right ahead.”
– George Lucas

Agile is about doing as opposed to being paralyzed by over-planning; in agile you get the minimal necessary requirements and start working.

Confuscus

 

 

 

 

 

 

 

 

6) “It does not matter how slowly you go as long as you do not stop.”
– Confucius

A core principle of agile is working at a constant pace, which in turn enables you to deliver at a constant pace, as opposed to working sporadically and delivering nothing.

Angelou

 

 

 

 

 

 

 

 

7) “We may encounter many defeats but we must not be defeated.”
– Maya Angelou

You will inevitably run into challenges along your agile journey, the key is to learn from these challenges and overcome them through standups and retrospectives.

Hawking

 

 

 

 

 

 

 

 

8) “Intelligence is the ability to adapt to change.”
– Stephen Hawking

Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the development teams must be ready to adapt.

Edison

 

 

 

 

 

 

 

 

9) “Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
– Thomas A. Edison

In agile as in life there will be hiccups, but the iterative nature of agile makes it easy to do a retrospective and learn from our mistakes then move on to the next sprint and do better.

Disney

 

 

 

 

 

 

 

 

10)”If you can dream it, you can do it.”
– Walt Disney

We should never forget that agile was formed to find a way to develop software better and to more easily conquer our dreams.

What is your favorite quote as it relates to agile?

Posted in Agile Adoption, Agile Benefits, Agile Project Management, Agile Teams, Continuous Delivery, continuous improvement, Uncategorized | Leave a comment

Why Agile Won’t Make You More Productive

PrintAccording to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity:

“Consistent with last year, most respondents adopted agile practices to accelerate product delivery (59%) or enhance their ability to manage changing priorities (56%). However, in 2014, productivity (53%) has moved into the top 3, outranking last year’s #3 response – improved IT and business alignment.”

This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I put my waterfall hat on and read the twelve principles that support the Agile Manifesto from a traditional stance. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

For example, a project that is managed with a traditional waterfall process has big upfront design and is transitioned over to a team that knows they have six to nine months to produce the software. At the beginning of project, the teams are more relaxed and moving slower. The intensity level and sense of urgency is a lot lower. Then as time goes on – three months, six months – the teams and management start to miscommunicate and stop being as diligent about status meetings. Near the end of the project suddenly the pressure and a bit of panic set in. Teams and management are panicking because now they have to scramble to get the software finished. Maybe this is what creates the perception with waterfall that your teams are not constantly producing software; there’s an ebb and flow.

Waterfall projects start out with very low intensity. By the end of the project the intensity is extremely high and teams are burned out because they’re working crazy hours. The teams are producing low-quality code because they have to rush and the code isn’t being tested. The low quality work damages the team’s pride, which decreases morale and can lead to turnover.

The benefit of going to agile is that the team maintains a constant level of intensity and consistent working hours, which in turn empowers the team to produce beautifully working software at a constant pace.

So when people are saying “productivity,” what I think they really mean is “intensity.” If we’re maintaining a constant level of working hours, a constant level of quality and a constant level of delivery, teams are happier, they’re proud of their work and they enjoy going to work. This is super important because keeping good developers is really difficult. If good developers aren’t happy they can easily leave and go somewhere else. That’s why 26% of respondents to the 9th annual State of Agile survey said improving team morale was the reason they adopted agile.

That’s my take on why there is a perception that agile is more productive than waterfall. When I saw the 9th annual State of Agile survey, I was curious about why people felt that if they moved to agile their teams were going to be more productive.

Why do you think there’s a perception that if companies go agile, teams will be more productive?

State of Agile is a trademark of VersionOne Inc.

versionone-coaches-susan-evansAbout the Author
Susan Evans
SAFe Agilist, CSP, CSM, PMP, PMI-ACP

Susan has more than eight years of agile project management experience in software development. Prior to joining the company, she was an internal coach who optimized the usage of the VersionOne platform to help many non-collocated teams thrive in their agile processes. Susan focuses on enhancing team relationships, communication skills, conflict resolution, and processes to help create happy teams that deliver high quality.

 

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management, Agile Teams, Uncategorized | 5 Comments