Category Archives: Scrum, XP and Lean

Kanban, Scrum, XP and Lean, Uncategorized

The Real Relationship Between Scrum & Kanban

3 Comments

(Image: Cover image of the book Essential Kanban Condensed by David J. Anderson and Andy Carmichael.)

Many people I interact with seem to believe that Kanban is another Agile methodology for helping Agile teams manage their work. The aim of this post is to help people see how Kanban can be so much more.

I am aware that there are some who believe that a high performing, self-organizing, cross-functional Agile team is as good as it gets and that it is the job of Leadership to change the organization such that this kind of team becomes a reality. This is a belief that I also held for many years, during which time I actively advised my clients to pursue this lofty goal and I invested a great deal of time and effort towards helping them achieve it. I understand this belief. It is very powerful, so powerful that it shapes identity. Therefore, it was a big part of my own professional identity and this was not easy for me to change. I empathize with those who struggle in similar ways as I have.

I could go on with my personal story, but I’ll get back to my opening statement. Kanban is so much more than just another Agile methodology. So what does this mean? How can it be so?

In my own experience helping businesses improve for over a decade and from the many stories I’ve listened to of the people I’ve met in my consulting engagements, training classes, conferences and meetups, the ideal of fully cross-functional teams is not a reality, not even a feasible possibility for their organizations and this reality is causing them pain and harm.

Let’s be clear about what we mean by cross-functional teams: According to the Scrum Guide (paraphrasing), a cross-functional team is a team that possesses all the skills required for starting and delivering potentially releasable product increments in a Sprint. A Sprint is a complete project that must be completed in one month or less. Many organizations add to this the idea of establishing stable teams (membership does not change) and Sprints of 1-2 weeks in duration. For many organizations, integrating all of the above is simply not realistic.

Most people I meet who are working with Agile teams (mostly Scrum teams) have already done everything they can to create the conditions for their teams to realize this ideal. Teams are already as “Agile” as they can be under the current constraints. Leaders have already done everything in their power to remove the constraints.

Some would describe this as a “failed Agile transformation”. But it need not be so. Rather, I have begun to see it as a natural stage in some organizations’ maturation process. Perhaps at an organizational level it is analogous to the “Storming” stage of the Tuchman maturity model: “Forming”, “Storming”, “Norming” and “Performing”. Regardless of the best analogy, the important point is that an apparent failed transformation does not have to be a bad thing. It also doesn’t mean you need to start all over again (with another re-org) in the hopes that you will “get it right” the next time. Rather, it is a natural stage of organizational maturation and the frustration, pain and conflict you are experiencing are telling you that your organization has an opportunity to evolve.

Kanban helps organizations move beyond this difficult stage. The Kanban principles of service orientation and evolutionary change help organizations focus on improving survivability of the business and the sustainability of the work. All of the Kanban practices are evolutionary stimulants for whole-organization improvements and they all scale naturally to all levels of an organization.

Kanban can help Scrum teams. Kanban can help with project, program and product management. Kanban can help with portfolio and enterprise services planning and management. Finding ways to implement the practices, little by little, at all levels of your organization will enable your organization to become fitter for the purposes of your customers, fitter for survival.

The Kanban Method, as opposed to other approaches, has built in double loop learning feedback loops. This makes it always contextually appropriate to help any organization. -Martin Aziz

The Kanban Principles:

Change Management Principles:

  • Start with what you do now;
  • Agree to pursue evolutionary change;
  • Encourage acts of leadership at all levels;

Service Delivery Principles:

  • Understand and focus on customer needs and expectations;
  • Manage the work, let people self-organize around it;
  • Evolve policies to improve outcomes.

The Kanban Practices:

  • Visualize the work;
  • Limit work in progress;
  • Manage the flow of work;
  • Make policies explicit;
  • Implement system feedback loops;
  • Improve & evolve with data, models and the scientific method.

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, coaching, culture, How-To Apply Agile, Miscellaneous, Scrum Master, Scrum, XP and Lean

An Analogy Between a Consultant/Coach and Paratrooper. Information and Adaptability is Key!

1 Comment

“Paratroopers are used for tactical advantage as they can be inserted onto the battlefield from … any location[. This] allows paratroopers to evade emplaced fortifications that exist to prevent an attack from a specific direction”

Excerpted from Wikipedia

I believe there are certain analogies between being a Paratrooper and being an Agile Coach or Consultant, including having strategic objectives, a purpose of infiltration, a sense of opposition, and a goal or cause that you believe in. However, I am not asserting that, a) implementing Agility at an organization is a declaration of war, b) Agility is a tactical warfare technique, or, c) being an Agile Coach or Consultant is synonymous to or nearly as dangerous a job as a Paratrooper.

Having said that, depending on the environment an Agile Coach or Consultant may sometimes feel like they are actually entering a corporate or political war zone. They are often viewed as outsiders posing a clear threat. They are often in the minority. They are often dropped in to unfamiliar territory. They often have incomplete or incorrect information. They are often surrounded by opposing forces. They are often made a target, either passively or aggressively. They often start with plans, but what makes them successful is their ability to adapt their plans and react to situations. In other words…be agile!

Like a Paratrooper, a Coach or Consultant is often “parachuted” or “inserted” in to an organization or foreign group with a specific mission. It is often to provide a “tactical advantage” and doing so helps a Coach or Consultant “evade emplaced fortifications [well established norms or strong opposition] that exist”, so they can get the job done from the inside and with less opposition.

A Paratrooper should always enter the field with a good understanding of the landscape, environment and situation. Similarly, a Coach or Consultant should also become familiar with the working environment and culture they are about to interface with. Without critical information both would risk the success of their mission and perhaps more. For a Paratrooper a lack of information could be life threatening, but fortunately the threat is not usually life threatening for organizational change agents.  It just might be professionally damaging to their career as well as others and their business.

 

Perform Reconnaissance

To that effect, I believe if you are a Coach or Consultant then you should still perform advance research for your intended mission in order for you to be successful, provide value and create an opportunity for learning and improvement. This means you will need to have conversations with both the leadership of their target (organization) and also with the people doing the work. Here’s why.

Leadership (usually the “paying customer” is management in the organization) should have specific and measurable outcomes they want achieved, and it is critically important for you to identify what those are up front and how they are expected to address their business problems. Meanwhile, the employees (usually the workers or teams) are often directly associated with and intimately familiar with the true needs and system issues, so you must also become familiar with their understanding for perspective. Unfortunately, the first battle is often that workers and their leadership do not align on their expectations and outcomes, and without their alignment you have little hope of true customer satisfaction and helping them collectively solve their real business problems.

As such, to manage expectations and increase chances for success it is critically important for a Consultant or Coach to investigate and identify both the needs of the leadership AND the needs of the employees, and then work to align them before any substantial work takes place. The best approach is to have face-to-face conversations with all the leadership and employees but that can take considerable time in a larger organization. So how do you get a realistic pulse of the company without talking to absolutely everyone?

 

Assess the Team

If the team(s) are using Scrum as a framework then one option is to use a Scrum team assessment tool like Scrum Insight. This tool provides objective coaching advice tailored specifically to a Scrum team as it is designed to detect how aligned the team is to Scrum practices and methods. The free version of this tool provides access to the basic report which contains the team’s overall scores, a “quick win” recommendation that identifies and provides suggestions that can be made to provide the biggest improvement on the team, and a list of support resources. The paid service provides everything in the basic report as well as a detailed Scrum Score Card, a Team Environment Score Card, a relative industry ranking, other education and support resources available for consideration, and it is usually followed up with a personal call to provide you with detailed explanation on the results.

Here is a sample Team Environment Score Card from Scrum Insight. Detailed descriptions for each bar/category are provided in the report:

SI Team Environment Score Card
Scrum Insight – Team Environment Score Card

 

Here is a sample Quick Win Report from Scrum Insight A more detailed description is provided in the report, and it is tailored to the team’s specific challenges and opportunities.

Scrum Insight - Quick Win
Scrum Insight – Quick Win

 

If you would like more information, you can also view a full sample report from Scrum Insight.

 

Assess the Organization

Another option is to conduct a REALagility assessment – either for a team, a group or an entire organization. The assessment is a 10 minute online survey conducted by every individual, and it is designed to uncover the misalignments between what leaders think and what employees think in an organization. The resulting report reveals the soul of the current culture, and it is grounded in real, actionable data to improve on the problem areas unique to the organization. As a Consultant or Coach these insights can be invaluable in helping you prepare for the engagement, identify opportunities, create alignment, and elicit real, meaningful and sustainable change for the organization.

Here is a sample diagram from a REALagility assessment, showing the relative rankings for an organization around five cultural measures. Detailed descriptions and insights for each cultural score are provided in the report.

Real Agility Assessment - Cultural Scores
Real Agility Assessment – Cultural Scores

 

Conclusion

In summary, I find it immensely helpful to “arm” myself with information prior to a Coaching or Consulting engagement, and these tools have been pivotal in filling that gap. Having early access to information such as this enables insights that might otherwise not be detected until I am on the ground helping the individuals, teams, and leadership tackle their business problems, which saves time, frustration, and money. An additional advantage with leveraging these electronic evaluations is that they provide an opportunity for people to provide ideas, feelings, agreements or disagreements that they may hesitate to share in a face-to-face interview.

There are certainly other tools that are designed to provide insights and information, but I’ve chosen these two because of my familiarity with them, and because of their effectiveness.

Of course, I would never replace good, valuable conversation with tools or data, but I do find these tools provide additional contextual information that further enables me to ask the right questions and have the right conversations early in an engagement. Finally, these tools can also be used as a benchmark for comparison of progress after a period of time has elapsed, which allows you as a Coach or Consultant to measure and be accountable for success.

 

Main Image – Paratrooper

Public Domain Image

http://www.acclaimimages.com/_gallery/_pages/0420-0907-2418-1546.html

Stock Photograph by Department of Defense Public Domain

Image Number: 0420-0907-2418-1546

 

 

 

 

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
agile teaching, agile training, Introduction To Agile, Scrum Master, scrum team improvement, Scrum, XP and Lean

A Litmus Test for Agility

3 Comments

Being Agile seems to be the rage these days and everyone has an opinion on what Agility means and how to do it “right”.  This article doesn’t make process recommendations, but it does provide a quick, effective way to help your team and organization get on track with being Agile (primarily a mindset measurement) and not just doing Agile (primarily a practices measurement).  Presented below is a simple and lightweight test that can be applied by almost anyone; it provides clear steps for improvement, and it is geared for alignment with the core Agile Principles and Values.

The Need

CoachThere are lots of Agile practitioners, coaches and trainers out there claiming to be experts.  Some are genuinely skilled while others have a few key certification letters beside their name and yet little to no in depth, real-world experience.  Although most have a genuine intent to help and they might actually succeed at it, others might inadvertently do more damage and provide harmful guidance.  How can you help them help you?

FrameworkThere are also numerous frameworks, methodologies, and practices that claim they are well suited to help an organization become more Agile.  Some of them are simplistic, process-based approaches that may not account for your environment, culture, or specific business needs, while others are more complex and pragmatic.  Depending on your situation it can be tricky to know what will work best.  How can you find a suitable fit?

MeasurementThere are also many tools and approaches to measure a team’s Agility, the leadership’s alignment with Agile, or the organizational maturity.  Some of these simply measure the number of practices (i.e. are you doing Agile), others account for an in depth assessment of cultural factors (i.e are you being Agile), and some are based on scenarios that are idealistic given common real world business challenges.

Indeed there are a wide variety of indicators of varying complexity, so you might be challenged to determine if they are simply vanity measures, helpful health indicators, or suitable fitness criteria, and more specifically if they appropriately measure for the outcomes you are looking for.  How can you ensure they are providing valuable insights and actionable results so you may make data driven decisions?

Keep it Simple and Focused

Given all these complexities, how do you know what it really means to be Agile, how can you align the effort, and how do you know how successful you are?

The answer is keep it simple and focused, and be outcome driven. Specifically, start with the foundations of Agile and then evaluate Agility from your perspective, your organization’s business needs, your employee’s needs, and most importantly from your customer’s needs.  Then, use that information to measure and steer improvement towards your real desired outcomes of Agility.

In the spirit of keeping it simple and focused, I’m sharing a “quick” and lightweight Agility Litmus Test and Procedure below to measure how you are doing and to ensure you, your stakeholders and your approaches are all headed in the right direction.

A Straightforward Procedure

1) Align With The Agile Manifesto

Read the Agile Manifesto.  I don’t mean gloss over it on the train on the way to work, or over lunch, or during your kid’s sports game.  I mean READ it, focusing on the twelve guiding principles AND the four value statements.

If it helps, boil each of the twelve principles down to two or three key words to provide clarity.  Then, when reviewing each principle ask yourself what you think it really means, and why you think it was important enough for the signatories to explicitly call it out in the Manifesto (what the intent was).  To ensure everyone has a similar frame of reference you may find it useful to host a time boxed, focused discussion on each principle.

2) Choose Key Agile Measures

Of the twelve principles ask yourself which ones (pick 3 or 4 at most) are core, or most important to you and your stakeholders (your organization, your leadership, your customers and your team).  Don’t just speculate or guess what the answers are; you will likely need to facilitate several workshops with the appropriate people to get to the truth to those questions.

This activity in itself is a test.  If there is not close alignment on what the most important principles are then stop right here.  Do not proceed until you align on what those key principles are.  If you proceed without alignment you risk working against one another and not towards a common goal or outcome.  Note that getting alignment might prove contentious so you may need a series of facilitated sessions to hash it out.

Once you align on several core principles they become your key indicators for the Litmus Test for Agility.  These are also your defined Agile outcomes, because they encapsulate what it specifically means for you to be Agile (where you want to be).

3) Perform a Critical Assessment

Starting with your key indicators, honestly answer the question how close or how far away are we” for each one.  Use a scale of 1 to 7, where 1 means “not close at all” and 7 means “we are totally nailing it”.  I chose 1-7 because it gives just enough range to differentiate measures.  That, and it is exactly 1/2 of the pH range for a proper Litmus test!

Be sure to seek fair and equal participation in this evaluation, as it is important to help reduce bias and ensure perspectives are accounted for.  This means you should ensure you have adequate representation from as many groups as is practical.

Honesty and transparency are also extremely critical here so you may require a facilitated session.  You may also need to provide a safe environment to encourage honesty in responses, so anonymous scoring and evaluations would be an appropriate technique to use.

4) Determine Actions

Critically review the summary of evaluative responses for your key indicators.  If the average is less than 6 out of 7 then hold a strategic planning session to determine actions to get you closer to achieving those outcomes.  Note also if there is a wide dispersal of the individual responses for a key indicator that would strongly suggest there is a large misalignment amongst the respondents, and you need to address that gap.

One question to ask would simply be “what would it take…”, or “what would we need to do to get us to a 6 or higher?   When following this line of reasoning be sure to account for the coaches, practitioners and experts you are relying on by asking “What can or should they be doing to align with our key indicators and Agile outcomes?”

Also, look at the frameworks and approaches you are using and ask “How can we switch, change or improve our ways to improve Agility?”

Finally, look at the tools and measures you are leveraging and ask “Are these vanity measures or are they really meaningful?” and “How can we improve these measures (not just the values, but the metrics themselves) to provide more meaningful insights and help us better realize our defined Agile outcomes?”

As a group then choose at least one and no more than three specific actions that came out of the discussion above, implement them, hold one another accountable for them, and measure on the next round if your actions had the desired effect of improving the scores for your key indicators.

5) Learn and Refine

Repeat steps 3 and 4 of this procedure at frequent and regular intervals, being sure to not only measure but also define and take new action.

6) Reassess and Pivot as Needed

If time permits or if your key indicators all show consistent strength, consider switching to some of the other Agile Manifesto Guiding Principles.  If it seems logical you may even want to go back and repeat the entire process as your needs and outcomes may have changed.

Conclusion

The core value this Litmus Test for Agility provides is a) in its simplicity, b) in it’s inherent alignment with the Agile Values and Principles, and c) in its focus on what matters most for you and your stakeholders.  It uses the Manifesto as a foundation, and then allows you to focus on what is most important to you.

Like all tests and models this approach has some inherent strengths and weaknesses.  For example, it is lightweight, cheap, easy to implement, and aligned with core Agility, however it is not an extravagant or in depth test so it may not account for complexities.  As such it should never replace sound judgement.

Meanwhile, if you sense or feel there is something deeper going on that may be impeding your organization’s ability to become more Agile then be sure to investigate thoroughly, work with others to obtain nonpartisan assessment, and provide clarity along the way on intent, outcome, and learnings.

If you are practicing Scrum, using a more sophisticated tool such as Scrum Insight (a virtual “Coach-in-a-Box”) can provide much richer, deeper feedback and insights, including recommended actions.  Even the free version of the tool provides keen insight.

Depending on circumstance you might also find it advantageous to call in expert facilitation, advisors or coaches to either conduct an Agility test such as this or even help your team or organization get to the heart of their issues and challenges.  Organizations such as BERTEIG are not only Agile teachers but they are also hands-on practitioners that can coach your team and organization to reaching new levels of Agility, either with a lightweight touch or a fully immersive engagement.

Coincidentally, reflecting, collaborating, providing transparency, and adopting a continuous learning and improvement mindset are in and of themselves indicators of Agility.  So identifying core values such as these and then making them part of your Agile Litmus Test (i.e. making them your new Agility outcomes) shows how simple it can be to improve, adapt and grow even this lightweight approach!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Announcements, How-To Apply Agile, Scrum, XP and Lean

The Scrum Team Assessment – Official Launch

Leave a comment

Hi Everyone,  I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve!  This is a fully automated Scrum maturity assessment tool!

The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results.  The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.

The analysis is both statistical and expert-system based.  This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements.  There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.

The Scrum Team Assessment includes a survey of about 100 questions that focus on seven broad categories:

  • The team’s environment
  • The basic Scrum process
  • The Product Backlog
  • Team Membership
  • ScrumMastering
  • Product Ownership
  • and Agile best practices

Every team member fills in the survey to help us generate a valid set of recommendations.

The Scrum Team Assessment is $496/team/use (that’s Canadian dollars).  If you have several teams or wish to obtain an enterprise license, please contact us at sales@berteigconsulting.com or +1-905-868-9995.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Links to Agile Info, Professional Development, Scrum Master, Scrum, XP and Lean

A Safe Approach To Developing High Performance Teams

Leave a comment
Jerry Doucett 201601 white background - head - 275 square
Improving Teams Means Changing Culture

By Jerry Doucet

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.

********************************************************************

Jerry is offering a number of SAFe training opportunities in Toronto, Ontario from September through December 2016. More details here. 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Scrum, XP and Lean, Theory of Agile

“Teams” Larger Than Eleven Are Not Scrum Teams

2 Comments

Mobbing Team

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:

  • People executing the work may be best suited to decide optimal team size and composition. Adjustments to team composition will be most effective if the team members are trusted (and supported) to re-organize around their own work.
  • Groups larger than eleven people often naturally subdivide into smaller, cross-functional sub-groups; therefore it may be possible to carefully observe which team members interact regularly while getting work done and simply acknowledge those informal arrangements.
  • In order to minimize dependencies between teams, Scrum Teams whose mandates are to own discreet Products or systems are preferable to groups whose mandates are to support “components” of larger systems.
  • Organizations which currently employ Project Management methods ought to consider changing budgeting & staffing practices to align around Product delivery rather than Project Management. Doing so will make value streams transparent and bring clarity to Product-centric team mandates.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Links to Agile Info, Scrum Master, Scrum, XP and Lean

Announcement: New Upgrades to The Scrum Team Assessment!

Leave a comment

MeetScrum

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:

  1. Scrum Scoring – How well your team is using Scrum;
    This includes measurement of the general process, the Product Backlog, the teamwork, and effectiveness of the ScrumMaster and Product Owner.
  2. Quick Wins – High impact ways to improve right now;
    The parts of Scrum you aren’t doing well that if you improve will give you the best return on your effort investment.  Specific, practical, applicable to your team right now!
  3. Long Term Recommendations – Sustaining high-performance;
    This is the harder stuff that involves the team’s environment, culture and processes and which can make a huge difference in the long term… but requires some up-front effort.  Practical suggestions to explore the creation of a high-performance Scrum team.
  4. Financial Benefits – The bottom line for the team;
    How much money is your organization wasting on poor performance, and how much can be saved by following the recommendations in the report.  Eye-opening, and the perfect motivation for management support of improvements.
  5. Industry Comparison – How your team is doing compares to others;
    Compare your team to other teams that have participated in the Scrum Team Assessment.  This comparison gets better and better as more teams use the Scrum Team Assessment.
  6. Recommended Resources – Tailored to your team.
    Books, articles, products, training and other services that will help your team rapidly improve.

Read more about the Scrum Team Assessment and try it for your team!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Scrum Master, Scrum, XP and Lean

Formula for Building a Successful Scrum Experience

Leave a comment

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

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Scrum, XP and Lean

The Retro Game

3 Comments

The Hunt for Better Retrospectives

The rumours had started to spread, retrospectives at our organization were flat, stale and stuck in a rut. The prevailing thought was that this was stalling the pace of continuous improvement across our teams. In truth, I wasn’t sure if this was at all true, it’s a complex problem that has many possible contributing factors. Here are just some possible alternative or co-contributing causes: how the teams are organized, the level of safety, mechanisms to deal with impediments across the organization, cultural issues, levels of autonomy and engagement, competence & ability and so on…

Despite this, it didn’t hurt to have a look for some inspiration on good retrospectives. I really liked Gitte Klitgaard’s talk called Retrospectives are Boring and Useless – Or are They? In particular the parts around preparing and establishing safety.

On the theme of safety, I thought we could try to go as far as having fun; we’d already had lots of success with the getKanban game (oh Carlos you devil!). Where it all tied together for me, was being inspired by the great question-based approach from cultureqs.com that I’d had a chance to preview at Spark.

If I could create a game with the right prepared questions, we could establish safety, the right dialogue and maybe even have some fun.

The Retro Game

This is a question-based game that I created that you could use to conduct your next retro for teams of up to 10 people. The rules of the game are fairly simple and you could play through a round or two in about 1 to 2 hours depending on team size and sprint duration. Prep time for the facilitator is about 2-4 hours.

theretrogame

Prepping to play the game

You, as facilitator, will need to prepare for 3 types of questions that are thought of ahead of time and printed (or written) on the back of card-stock paper cards.

One question per card. Each question type has its unique colour card. About 8 questions per category is more than enough to play this game.

The 3 types of questions are:

In the Moment – These are questions that are currently on the mind of the team. These could be generated by simply connecting with each team member ahead of time and asking, “if you could only talk about one or two things this retro, what would it be?” If for example they responded “I want to talk about keeping our momentum”, you could create a question like “what would it take to keep our momentum going?”

Pulse Check – These are questions that are focused on people and engagement. Sometimes you would see similar questions on employee satisfaction surveys. An example question in this category could be “What tools and resources do we need to continue to be successful?”

Dreams and Worries – This is a longer-term view of the goals of the team. If the team has had any type of Lift Off or chartering exercise in the past, these would be questions connected to any goals and potential risks that have been previously identified. For example if one of a team’s goal is to ship product updates every 2 weeks, a question could be “What should we do next to get closer to shipping every 2 weeks?”

On the face-up side of the card it should indicate the question type as well as have room to write down any insights and actions.

You will also need:

  • To print out the game board
  • To print out the rule card
  • Bring a 6-sided dice

Playing the Game

Players sit on the floor or at a table around the game board. The cards are in 3 piles, grouped by type, with the questions face down.

therules

  • The person with the furthest birthday goes first.
  • It is their turn and they get to roll the dice.
  • They then choose a card from the pile based on the dice roll. A roll of 1 through 3 is an “In the Moment” card, 4 is a “Pulse Check” and 5 to 6 “Dreams & Worries”
  • They then read the card question on the card out loud and then pass the card to the person on the right.
    • The person on your right is the scribe, they will capture notes in the Insight and Actions boxes of the card for this round.
  • Once they have read the question, they have a chance to think and then answer the question out loud to the group. Nobody else gets to talk.
  • Once they’ve answered the question, others can provide their thoughts on the subject.
  • After 3 minutes, you may wish to move on to the next round.
  • At the end of each round the person whose turn it was chooses the person who listened and contributed to the discussion best. That person is given the card to keep.
  • The person to the left is given the dice and goes next.

Winning the Game

  • The game ends at 10 minutes prior to the end of the meeting.
  • At the end of the game, the person with the most cards wins!
  • The winner gets the bragging rights (and certificate) indicating they are the retrospective champion!
  • You should spend the last 10 minutes reflecting on the experience and organizing on the action items identified.

Concepts at Play

players-playing

Context & Reflection – Preparation is key, particularly for the “In the Moment” section. The topics will be relevant and connect with what the team wants to talk about. Also when presented in the form of a question they will likely trigger reflection for all those present.

Sharing the Voice – Everyone gets a chance to speak and be heard without interruptions. The game element also incentivises quality participation.

Coverage of topic areas – The 3 question categories spread the coverage across multiple areas, not just the items in the moment. The probabilities are not however equal, for example there is a 50% chance of “In the Moment” being chosen in each turn.

Fun & Safety – The game element encourages play and friendlier exchanges. You are likely to have dialogue over debate.

Want to play the game?

I’d love to hear how this game worked out for you. I’ve included everything you need here to setup your own game. Let me know how it went and how it could be improved!

Resources:
Retro Game – Game Board
Retro Game – Rules
Retro Game – Card Template
Retro Game – Champion Certificate

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

Business vector designed by Freepik

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Scrum, XP and Lean

Breaks Between Sprints Indicate a Problem

Leave a comment

This post is a follow-up to an earlier article: There Are No Breaks Between Sprints.

Breaks between Sprints indicate a problem. Usually such breaks are filled with planning activities including research, requirements gathering, design & preparation, negotiations & approvals and the problem is threefold:

  1. Such plans are based on conjecture (risky and not compatible with Scrum) rather than empiricism (less risky and compatible with Scrum). Those activities are most beneficial when diligently performed by skilled inspectors at the point of the work. The four formal events within each Sprint provide the team and stakeholders adequate opportunity for inspection and ensure that decisions are being made in light of the up-to-date product increment and with respect to current user needs and market conditions.
  2. Breaks between Sprints often include activities which do not add value to the product or are entirely unrelated.
  3. Breaks between Sprints defer the delivery of value because the work performed does not result in potentially-releasable increment of “Done” product.

To correct this problem it is important to identify whether any of the effort spent between Sprints is adding value to the product — that is, which activities effect the form, fit, or function of the actual product. If determined to not be value adding, stop the activity entirely — it is waste. If determined to be value adding then the work ought to be part of their Sprints and the Scrum Team may decide that either the activity should be represented and ordered in the Product Backlog, or should be represented in the team’s Definition of Done.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Scrum, XP and Lean

Splitting User Stories

2 Comments

A common challenge faced by inexperienced Scrum teams is related to splitting user Stories (in Scrum, Product Backlog Items or PBIs) so that they are granular enough for development. The INVEST model is a good way to test whether user stories are well-written.

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

Independent – Each user story must be independent of each other. This prevents any overlap between the items; moreover, it allows the team to implement them in any order.

Negotiable – The details of the work must be negotiable, both among the stakeholders and the team. Specific requirements and design decisions will be fleshed out during development. Many agile practitioners recommended writing user stories on a note card — this is intentional so that a limited amount of detail can be prescribed.

Valuable – Each user story must add business value to the product, the customer and/or the users’ experience.

Estimable ¬– A good user story can be understood well-enough by the team that they can estimate it — not accurately — but at a high-level they perceive that it has size. It is helpful to understand the relative effort as compared to other user stories.

Small – A user story is not small if the team cannot get it done within a single Sprint. As large user stories are split into smaller items, greater clarity about the size and implementation is achieved, which improves the likelihood that the team will get it done within a Sprint.

Testable – Each user story should be testable; this is a common characteristic of well written requirements. If the team cannot determine how the user story may be tested, it is an indication that either desired functionality or the desired business value is not clear enough.

Vertical vs Horizontal Splitting

There are two common ways to split user stories: vertically or horizontally. Horizontal breakdown of user stories splits the item at an architectural component level. Example: front end UI, databases or backend services. Whereas, a vertical slice results in working, demonstrable, software which adds business value. Therefore, it is recommended to slice user stories vertically so as to reduce dependencies and improve the team’s ability to deliver a potentially shippable product increment each sprint.

Splitting User Stories Example

As a customer I can pay for my order so that I receive the products

If the above user story was to be split in a vertical manner, it might be broken down into the various ways a customer can complete a payment. As follows…

As a customer I can make a credit card payment for my order so that I collect reward points on my credit card.

And/or

As a customer I can make a PayPal payment for my order so that I can securely complete my purchase without sharing credit card details with another retailer.

The key point to note in the vertically sliced user stories above is that each story passes the INVEST tests mentioned earlier and therefore a Product Owner can prioritize these user stories based on customer needs. However, if a horizontal approach was used to split the user story (i.e. split by architectural layers and components) then the implementation of such requirements would result in working functionality only when all horizontal components are eventually integrated.

Breaking down by Workflow

Another approach that is commonly used to breakdown user stories is focused on the individual steps a user may take in order to achieve their end goal — that is, a user story which describes a long narrative or “user flow” through a system may be sliced into steps which represent portions of the user’s flow. Continuing from the example above of a customer making a purchase online, the user story can be broken down into the following:

As a customer I can review the items being purchased for my order so that I can be confident I’m paying for the correct items.

As a customer I can provide my banking information for my order so that I can receive the products I ordered.

As a customer I can receive a confirmation ID for my purchase so that I can keep track and keep a record of my purchase.

Other Methods

There are many other methods that can be utilized to breakdown larger user stories such as:

  • Breaking down by business rules
  • Breaking down by happy / unhappy flow
  • Breaking down by input options / platform
  • Breaking down by data types or parameters
  • Breaking down by operations (CRUD)
  • Breaking down by test scenarios / test case
  • Breaking down by roles
  • Breaking down by ‘optimize now’ vs ‘optimize later’
  • Breaking down by browser compatibility

Kudos to this article for inspiring the list above: blog.agilistic.nl.

Other Helpful Resources

The Hamburger Method
User Stories and Story Splitting at AgileAdvice.com

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Professional Development, Scrum, XP and Lean, Theory of Agile

Refactoring: 4 Key Principles

4 Comments

I believe in refactoring.  The Agile Manifesto holds that

The best architectures, requirements and designs emerge from self-organizing teams.

The quality of our software systems depends on refactoring.  In fact, I believe that the only way that an organization can avoid refactoring is by going out of business.  Maybe I should explain that.

Refactor or Die

Heart Monitor Flatline - Refactoring or DeathEvery software system that we build is inside a dynamic environment.  The organization(s) using the software are all in a state of constant change.  The people using the software are also constantly changing.  Due to this constant change, every software system needs to be adapted to the environment in which it is used.  Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle.  Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security.  But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities?  I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex.  Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about.  It is pretty easy to see how this works – for someone who has a technical background.  But for those without a technical background it can be hard to understand.  Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids.  In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature.  After a few weeks of doing this, you realize that it would be helpful to have the date on the form.  You do this so that you can enter their allowance payments in your personal bookkeeping records.  Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment.  Then your kids want extra allowance for a special outing.  So you add some things on the form to allow them to make these special requests.  Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes.  So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes.  Your form is getting quite complex by this point.  Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances.  Every new situation adds complexity to the form.  The form expands over multiple pages.  Filling out the form weekly starts to take significant time for each child and for you to review them.  You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet.  You decide you need your own checklist to make sure that the forms are being filled out correctly.  A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version.  It takes three days, and there is lots of guess-work.  Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step.  The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Technical Debt and Design Death

Technical Debt and Design Death: Part II

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features.  If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence.  What are the other options in that decision?  Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while.  Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details).  At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system.  Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

In other words, refactor or die.

Refactoring and Business

Refactoring and Business Success - Growth ChartIn the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring?  How do we “govern” it?  How do we make good decisions about refactoring?

There are a few principles that are important in helping to answer these questions.  All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum, OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches.  The worst extreme is the complete system re-write refactoring.  The best refactoring activities take seconds or minutes to execute.  Small refactorings create a constant modest “overhead” in the work of the team.  This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small.  For example, upgrading a component or module from a third party might show that your system has many dependencies on that module.  In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously.  This allows your system to be partially refactored.  In other words, to break a large refactoring into many small refactorings.  This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem.  Your own system may have a major component that needs to be re-written.  Again, finding creative technical means to allow for incremental refactoring of the component is crucial.  This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously.  One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it.  Instead, the technical team needs to use business requests as catalysts for refactoring.  If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature.  In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date.  This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code.  So, instead, we need to allow the technical team to refactor when they detect duplication.  Duplication of code, data or structure in the system.  A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result.  But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution.  Later, the business makes another request that also implies the same large refactoring.  Now is the time to seriously consider it.  It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies.  However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration.  In refactoring work, teamwork applies just as much as in any other activity.  Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring.  But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring.  Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring.  This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes from collective code ownership and trust.  Usually, this is built from practices such as pair programming or mob programming.  These practices create deep levels of shared understanding among team members.  This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support.  It also impacts research and learning processes so that teams can do experiments and try alternatives quickly.  All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring.  This can be difficult at first.  Another analogy helps to see the value of this.  A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc.  In fact, all of those things contribute to the cost of surgery.  A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them.  Likewise, software professionals need to be open about the costs of refactoring.  This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest.  Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs.  Respecting the team and trusting their decisions can sometimes be very hard.  Teams sometimes make mistakes too, which complicates trust-building.  The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring.  Ideally, it is continuous, small, and low-level.  But once in a while, a team will have to do a large refactoring.  How do you know if the cost is legitimate?  Unfortunately, as a non-technical stakeholder, you can’t know with certainty.  However, there are a few factors that can help you understand the cost and it’s legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Links to Agile Info, Scrum, XP and Lean

Example of Visualizing Process Cycle Efficiency with LEGO

Leave a comment

In-depth article here: Using Lego[sic] to capture raw data for Cycle Time and Process Cycle Efficiency.

From the article:

The typical way to collect baseline numbers for these metrics is to conduct a value stream mapping workshop that involves most or all team members for one day or longer. The client is worried about losing too much time in the workshops when the teams could be doing value-add work. Therefore, we needed a less intrusive way to collect baseline measurements. There is also the question of how accurate the PCE data will be when it is obtained through a workshop rather than by direct observation of team activity.

I came up with the idea of using Lego bricks to collect the raw data for Cycle Time and PCE. There is some impact on team member time, but hopefully it is not too intrusive. My observation is that people enjoy manipulating Lego bricks, and they don’t mind sticking the bricks on a plate to represent their work.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Scrum, XP and Lean

The Daily Goal

15 Comments

When my Scrum team first proposed trying mobbing I wasn’t sure what to expect. No one on the team (including myself) was an expert. I reserved judgment and watched a few sprints. I stayed silent when the same team decided to skip the tasking out portion of planning and simply pulled in enough stories to fulfill their Sprint goal.

After a couple of sprints it became obvious that there were a number of pros; the team was engaged and aligned. They responded as a consistent, unified voice at Sprint Review and Retro. Planning went a lot faster as the team no longer wrote out all their tasks and didn’t have to copy all of them into Jira.

In particular, the Daily Standup’s usual agenda of “what did you do yesterday? what are you doing today? what are you doing tomorrow?” became redundant. And this had me thinking; ‘maybe the team didn’t need a stand up anymore? What’s the point?”

Then, one of the team members introduced me to the concept of the daily goal and I watched as he walked the team thru it. I thought this made a lot of sense and so did the team. We kept up the practice. Some days the team would forget about it or be too tired to bother. I noticed on those days the team wouldn’t be as clear on what they were working on or how to align on a particular challenge. I also noticed that the Stand Up the next day would be more fragmented and meander a bit. They would forget to communicate to one another and look at me as their Scrum Master expectedly, wanting me to drive it.

I started to coach the team back to their daily goal practice and reminded them this Stand Up was for them to align on the work ahead for the day. This became more important as the team divided up into mini mobs or pairs and were no longer one big mob.

I find the Daily Goal useful for a number of reasons. Instead of tasking out the work a week in advance, they decide how to approach the work on a daily basis that takes into account any day to day changes that have happened. Planning goes a lot faster now that we’re not tasking out all the work in advance. The team stays focused on a daily basis as opposed to at just Planning. They write their daily goal on their Scrum Board making it visible to anyone on the floor what their focus is for the day. Even better, the daily stand up as renewed purpose and the dialogue is more interactive.

Here are some examples of our Daily Goals:

  • Refactor Story 1
  • Coordinate with outside team members to align on test strategy
  • Complete happy path for Story 3
  • And sometimes it is as simple as “Complete story 4”

I hope to continue the practice and frankly, it’s fun! Achieving short time goals is motivating and brings a sense of accomplishment. I highly recommend it. Let me know your thoughts and if you’re trying this technique let me know how it’s working out for your team.

[EDITOR’S NOTE: Alexandra Dragon is a first-time contributor to Agile Advice – please welcome her in the comments.  And let us know if you are interested in contributing.]

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Agile Management, How-To Apply Agile, Scrum, XP and Lean

The Real Daily Scrum

2 Comments

On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details