Skip to content


Why do you want to become agile?

Ben Linders - Mon, 08/08/2016 - 13:16

Why becoming agileBecoming agile can help to achieve organizational goals. But setting agile as a goal for an organization does not work. The goal for a software organization should be to achieve results by delivering valuable products and services, not to become agile. Hence my question: do you know why do you want to become agile?
Yes, seriously, why would you do agile? There are lot’s of good reasons (and also some less good ones), but what’s your reason to become agile? What do you expect from agile?

Agile transformations seriously impact organizations (they should!). It’s a reorganization of people, work, and authorities. Employees are asked to think about the way they want to do their work, and to take responsibility. Managers have to give room to their employees. There must be a good reason to do all of this. You should know the reason why you want to become agile, and let everyone involved know.


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

It is important to know why you want to increase the agility of your organization and what you expect to achieve with agile. To know why would you want to work in an agile way, why you want your culture to become agile.

Again, agile is not an goal or state that needs to be reached. It’s important that every manager and employee knows why the organization starts an agile journey and what is expected from agile. Reasons to become agile

If I ask people in organizations that I work with why they want to become agile they often look surprised at first. Of course they want agile! Everybody is doing agile, so it must be good. Agile is supposed to make them faster, cheaper and better. So let’s do it. If it only was that easy … every organization should be truly agile by now.

Does knowing the reason matter? Yes, it does! If you know the reason why you want to become agile, chances of success increase significantly. If people know why they have to chance, if they see the purpose, they are more willing to do it.

Some of the reasons that I have heard in organizations on why they want to become agile are:

  • Deliver the right products and services
  • Be able to deliver faster
  • Increase customer satisfaction and win new customers
  • Create innovative products with motivated employees
  • Reduce the cost of development and management
  • Improve the quality of goods and services
  • Effective cooperation between development and management
  • (your reason here)

My advice to companies is to think about why they want to become agile. Pick one reason, and one only. State very clearly in one sentence what your main objective to become agile. What would make your agile transformation successful. Going for one goal is hard enough. Also, the reason you choose impacts the way that agile will be applied (it should!), so choose your reason carefully. What is your goal with agile?

Do you want to deliver products with good quality? Or be able to better meet the needs of your customers? Lower your costs? Increase the motivation of your employees? Whatever your reason is to become agile, contact me, and I’ll help you to get results :-).

Categories: Blogs

Second book is coming soon…

Agile In Action Blog - Staffan Nöteberg - Mon, 08/08/2016 - 12:01


It’s six years since Pomodoro Technique Illustrated was published. It’s translated into many languages and there’s 250 000 copies sold. Now, the sequel is almost here.

Cover image for my second book is ready. Full manuscript is written. Chinese publisher signed and translator is working hard. English publisher to be presented soon. It’s an exciting time. I hope you’ll enjoy the book and that it’ll make you more successful.

Categories: Blogs

Books by Ben Linders on Leanpub

Ben Linders - Mon, 08/08/2016 - 11:07

Books Ben Linders LeanpubAll of the books that I have published on Leanpub are now available in a bundle: Books by Ben Linders. You get a 30% discount when you buy my books with this bundle.

Currently this bundle contains three books:


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

My book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!

My book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.

My 2nd and 3rd book are being written incrementally. Currently they are only sold via Leanpub. When you buy the book on Leanpub you will automatically receive new chapters when they become available, free of charge.

All books that I will publish in the future on leanpub will be added to this bundle.

Categories: Blogs

Anti-Patterns impacting Customer Value

Value is in the eye of the beholder.  Smart people will say that the beholder is the customer. While in most companies there will be a similar saying to the “customer is king”, some have lost their way and have somehow forgotten the importance of customer and their feedback.  The result is organizational anti-patterns that impede successfully getting to customer value. There are a number of anti-patterns on why this occurs and below are four: 
  • Believing that you can pretend to know with certainty what the customer wants upfront.  The danger: the consequence of limiting options and being blind to customer feedback to shape product direction.  Otherwise known as the Pretend Certainty anti-pattern.
  • Focusing primarily on driving efficiencies through cost cutting and high resource utilization.  The danger: the unintended consequence of a lesser focus on the customer with little room to innovate and adapt.  Otherwise known as the No Room at the Innovation Inn anti-pattern.
  • Sub-optimizing for the comfort of having a well-established plan and set of well-defined processes.  The danger: the consequence of restricting change at the expense of adapting to customer needs.  Otherwise known as the Sub-Optimizing for Comfort anti-pattern. 
  • Engaging few to represent the whole.  The danger: the consequence of understanding customer pool, ignoring potential customers, and missing customer feedback to shape product direction. Otherwise known as the The Few and the Missing anti-pattern.

When you are a start up, you realize the importance of being customer value driven because if customers don’t buy the product, then your start-up goes under. Because of this and their small size, most start-ups will stay very close to the customer or potential customer.  When companies become larger, there is a greater chance these anti-patterns appear.  More process and more controls are often put into place and unfortunately this leads to restricting change.  A company may sub-optimize for their own processes and plans that distances them from their customers.  
The question is, do you see any of these anti-patterns within your organization that impact your ability to achieve customer value?  Avoid the poor “aim of the anti-pattern’.  Instead, engage with your customers and use their feedback to help you hit the customer value target!
For more information on the topic of Customer Value, consider reading the following articles:

Categories: Blogs

ANNOUNCEMENT: New Course Offering — Writing Defect-Free Code Faster!

Learn more about transforming people, process and culture with the Real Agility Program


The ONLY Certified Scrum Developer (CSD) Training offered in Canada! This highly-coveted Scrum offering is certified by the ScrumAlliance and counts toward 21 PDUs or SEUs.


Writing Defect Free Code Faster! – This 3-Day course will prepare you for all that a Professional Developer will encounter in an Agile environment.

  • – Learn how to write defect free code that will be easy to manage over the long-term.
  • – Understand why test driven development is the key to successful product development.
  • – Delight your stakeholders and customers by giving them exemplary software.


Toronto, Ontario


September 13 & 14, 2016

Who? Instructed by Senior Agile Coach Mike Bowler!


Participants also receive two free books after attending the CSD training. The first book is Mishkin Berteig’s collection of the best articles from our blog Agile Advice. This book includes a multitude of useful and insightful articles about all things Agile. The second is a book of your choice from our list of recommended reading! These are the most important books for people using Scrum: books about technical topics, processes, the human side of Agile, and even corporate culture.



More about Certified Scrum Developer Training from Scrum Alliance:

Certified Scrum Developers have demonstrated, through a combination of formal training and a technical skills assessment, that they have a working understanding of Scrum principles and have learned specialized Agile engineering skills. The Certified Scrum Developer® course is aimed at software developers (programmers) who are building software in a Scrum environment. The goal is to expose students to the most important tools and techniques that need to be applied in order to build good software in the iterative and incremental fashion that Scrum requires. These ideas are central to the entire field of Agile software development.” –


By earning a Certified Scrum Developer® certification you:

  • Learn the foundations of Scrum and the scope of the Certified Scrum Developer’s role from the best minds in Scrum.
  • Demonstrate to employers and peers your attainment of core Scrum knowledge.
  • Expand your career opportunities by staying relevant and marketable across all industry sectors adopting Agile practices.
  • Engage with a community of recognized Scrum experts who are committed to continuous improvement.

As a CSD, you will also have access to a two-year membership with Scrum Alliance. Through this membership you can join local user groups and online social networks, gain access to deep discounts on gatherings and member-only resources.




Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post ANNOUNCEMENT: New Course Offering — Writing Defect-Free Code Faster! appeared first on Agile Advice.

Categories: Blogs

“Teams” Larger Than Eleven Are Not Scrum Teams

Learn more about transforming people, process and culture with the Real Agility Program

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.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post “Teams” Larger Than Eleven Are Not Scrum Teams appeared first on Agile Advice.

Categories: Blogs

What Do We Mean By Welcoming Complexity?

Learn more about transforming people, process and culture with the Real Agility Program

05 All of Scrum Diagram - Branded

A few weeks ago, Agile Advice featured an article called Face-To-Face Value highlighting the first of the Agile principles which is that face-to-face interaction is valued above technology-supported contact such as email, text or even Skype.

Recently, I came across another fantastic article written by Peter Green on his blog Agile For All. In the post, “What Do We Mean By Welcoming Complexity,” he reminds readers of the second Agile principle, namely,  that we “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

His description of the concept of welcoming complexity is so inspiring that I was moved to sign up to the newsletter. No, I’m not a sponsor but I just wanted to share this enlightening reminder of one of the reasons Agile-thinking is so profound.

In the quick-fix, easy-is-better world we live in, it sure is refreshing to be reminded that welcoming complexity is worth it! When we welcome complexity we grow, we change, we become better people and the teams we work with advance because of it!



Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post What Do We Mean By Welcoming Complexity? appeared first on Agile Advice.

Categories: Blogs

Apply the Agile transformation to real challenges, immediately (success factor 2 of 6)

Bruno Collet - Agility and Governance - Sat, 08/06/2016 - 16:03
The key principle here is to remember that people learn better by doing than by hearing or thinking about something. By doing they discover firsthand the superior results of the new behavior or practice.

Additionally, people involved in Agile transformation are very busy. They already spend 110% of their time on everyday work and all the rest tends to come on top. The Agile transformation, while strategic-and-super-interesting, competes with their daily whirlwind. The only way that participants give a chance to new behaviors is to make sure they are relevant to challenges they're facing, and that they are actionable almost immediately. Or else the learning will probably be lost.

"The only way that participants give a chance to new behaviors is to make sure they are relevant to challenges they're facing."
How do we quickly put people in action in the Agile transformation?
Don't spend too much time strategizing the Agile transformation. An Agile transformation is itself an Agile project: we plan what we can, and elaborate progressively as we learn from the feedback of concrete actions. In uncertain situations (see VUCA), strategy emerge from actions much more than actions come from strategy.

Design together a high-level roadmap made of a few phases and a few transversal streams for recurring topics (i.e., leadership, continuous value delivery…) and select together right away a few actions to apply to real work. Proceed then iteratively in plan-do-check-act (PDCA) cycle. This approach also keeps participants engaged since the Agile transformation program helps them in their everyday job.

In a 6-month Agile transformation program I was recently involved, I could put participants in action on real challenges after only three weeks. This short period was dedicated to better understand the context, generate awareness and desire to change, and elicit the overall transformation strategy and roadmap. All of which are minimal steps before participants can take effective actions.

This type of approach is sometimes referred to as action-learning.

It's equally important to attach the Agile transformation to a value-creating initiative that benefits from it. The selected initiative must be sufficiently strategic and cover similar organizational scope in order to have transformational potential. By piggybacking on a strategic, transversal initiative, the Agile transformation gains traction. For example, I had the opportunity to initiate an Agile transformation through a digitization program which spanned several functions and required developing Agile behaviors at all levels. Conversely, avoid doing a stand-alone Agile transformation project. I could not have gained access to people or have had real impact if I had initiated the Agile transformation in a vacuum. In short, don't do a "change project", do "the cultural transformation part of (for example) the digitization program".

Pitfalls to avoid
  • A detailed strategy up-front
  • An analysis phase or too many proofs of concepts
  • "Generic" Agile transformation - Not applying the Agile transformation to real initiatives
  • Waiting too long between talking about Agile and doing/being Agile
  • Relying on training and courses and expecting that learnings will naturally be put in practice

Next: Scope the Agile transformation consistently with behaviors to change (success factor 3 of 6)Previous: Develop Agility for business reasons (success factor 1 of 6)The 6 key success factors to start an Agile transformation the right way
Categories: Blogs

Announcement: New Upgrades to The Scrum Team Assessment!

Learn more about transforming people, process and culture with the Real Agility Program


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!

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Announcement: New Upgrades to The Scrum Team Assessment! appeared first on Agile Advice.

Categories: Blogs

Links for 2016-08-05 []

Zachariah Young - Sat, 08/06/2016 - 09:00
Categories: Blogs

How RabbitMQ Saved My SaaS

Derick Bailey - new ThoughtStream - Fri, 08/05/2016 - 13:30

Years ago I was building a distributed system that had to function with and without a network connection.

It was a standalone app for vehicle maintenance that would synchronize data with a central server.


After a lot of trial and error, I decided to use a message queue.

It handled the system’s needs perfectly. I could batch up messages while disconnected and when the connection came back, the system would send the messages.

This was the first time I used a message queue, but I was hooked instantly.

During that first project, I saw the potential power of message based patterns. From Windows to the web, my code would benefit from this new-to-me architectural style.

I built applications and frameworks – including Marionette.js on top of Backbone – with ideas that dramatically simplified complex system design.

Life was good on the front end, for the Windows apps and my JavaScript / Backbone code.

Fast forward a few years and I was building a SaaS app.

Things were going well, but as traffic grew the site was slowing down and putting strain on the database. External service calls were overwhelming the network. Code was failing and the site was crashing!

I had to do something… but, what?

I knew what I wanted to do – to take the slow code out of my Express route handlers. But I didn’t know how… at least, I thought I didn’t.

It wasn’t until I saw connectivity issues with external services that I started thinking about a message queue – the same tool that had helped me with the offline/online app, years ago.

So I did some research, not knowing what was available for free / open source message queueing.

And I found RabbitMQ.

After taking some time to educate myself and painfully work through learning RabbitMQ, I very nervously wrote and deployed my first bits of code with it.

The result was incredible.

My service went from handling a few hundred requests per minute, to tens of thousands. My SaaS was alive and healthy, again!

I could scale the back-end code separately from the web server. The system could more easily recover from catastrophic failure. And once again, I was building complex systems in small chunks that are easier to work with.

And it’s all thanks to messaging with RabbitMQ.

But… learning on your own tedious, at best.

There’s new patterns to try, new language to understand, and new code to write.

It can take months, even years, of working with a new technology on your own, to master it.

I’ve been down the path of self-learning with message queues and the associated patterns. I know how long it takes to get from where I started to where I am today.

I don’t want anyone else to travel this path alone.

For that reason, I’ve put together the fastest way to cross the chasm.

The RabbitMQ For Developers package is the resource on learning what you need to know, and why.

And if you want an inside look at the course, sign-up below. You’ll get a preview of the course that has helped hundreds of developers save their SaaS, apps and architecture.

Categories: Blogs

Six Years of Scaling Mountains

Leading Agile - Mike Cottmeyer - Thu, 08/04/2016 - 23:09


Hey everyone… thought it was worth noting that LeadingAgile had our six year anniversary this week. It’s been a hell of a run from just Dennis and I to over 60 people. I want to thank all the loyal readers of this blog… our customers… our employees… and all the awesome folks that have guided and supported us along the way. You guys have been great. Thank you!

The post Six Years of Scaling Mountains appeared first on LeadingAgile.

Categories: Blogs

Link: Mommy Dojo Kanban – First Month Review

Learn more about transforming people, process and culture with the Real Agility Program


Right from the beginning of being introduced to Agile concepts in 2013, I appreciated the word “agile” because of its easy cross-over to sports and athletics.

Last year, around the same time that I started Taekwondo classes I also started working with an agile coach on an introductory e-course for agile beginners. As I was newly developing physical and mental agility in training while simultaneously deeply reflecting on and learning new agile concepts, the metaphor of a Scrum Master being like a Black Belt really stuck a cord for me.

Recently I came across another agile-enthusiast who is also a mother, a martial arts practitioner, and a strong advocate for personal Kanban. She authored a blog called  “Scrum Family” from 2008 until 2015. I find her posts light-hearted but strong, engaging and intelligent.

Here is a link to one of my favourite of her posts where she summarizes a successful month-long “Mommy Dojo Kanban” initiative.

She wrote that, “The Mommy Dojo Kanban really works for me. It’s simple, practical and easy to maintain. The horizon is the next seven days only. When that’s done, I simply reset without sweating major analysis or statistics.”

I was encouraged by her enthusiasm, organization and perseverance and am excited to try out a few of her Kanban tips myself.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Link: Mommy Dojo Kanban – First Month Review appeared first on Agile Advice.

Categories: Blogs

Team Performance Model - by Drexler and Sibbet

Agile Complexification Inverter - Thu, 08/04/2016 - 19:28
Many of you have all heard of the Tuckman model of team dynamics (Forming, Storming, Norming, Performing).  It was created in 1966 and has become the most popular model for describing team behavior.  Is it time to level up in your mental model of team dynamics?  Are you ready for a richer more functional model?

Introducing the Team Performance Model by Drexler and Sibbet

Orientation - Why am I here?
"Orientation is about understanding the purpose of a team and assessing what it will mean to be a member.  you need to understand the reason the team exist, what will be expected of you and how you will benefit from membership.  In a new team, these are individual concerns, because the group is only potentially a team.  that is why these concerns are illustrated as occurring in your imagination at an intuitive level.  As a team leader it is important to provide time and space for people to answer these internal questions themselves."

Keys to when Orientation challenges are resolved:
 - Team Purpose
 - Team Identity
 - Membership

Blocked teams at stage 1 Orientation may show...
 - Uncertainty
 - disorientation
 - Fear

Trust Building - Who are you?
"Trust is a measure of your willingness to work together with others for something important.  Because team members have to depend on each other to be successful, trust is essential in direct relation to how much cooperation is needed to get the job done.  In the beginning of a new team's live, trust involves some risk and uncertainty about dealing with strangers.  This is why the key question is "Who are you?"  An unstated aspect of this question is wondering, "What will you expect from me?"  For a team to work well, you need to accept that you can depend on team members to work together to accomplish the team's purpose."

Keys to when trust challenges are resolved:
 - Mutual regard
 - forthrightness
 - Reliability

When a team is Blocked at stage 2, members may show...
 - Caution
 - Facade
 - Mustrust

Goal Clarification - What are we doing?
Sometimes teams have precise charters that specify what they are responsible for accomplishing.  More often, they are given a broad mandate and nee to make choices about how they will pursue that mandate and translate it into goals.  "What are we doing?"  is a more specific question than the larger question of purpose asked during Orientation.  During this stage of a new team's life, it will need to do research and develop clear understanding of the job that is required, as well as generate agreements about goals and specific deliverables."

Keys to when goal clarification challenges are resolved:
- Explicit Assumptions
- Clear integrated goals
- Shared vision

Blocked at stage 3, members may show....
- Apathy and skepticism
- Irrelevant competition

Commitment - How will we do it?
"When goals are clear and options are identified, your team is probably eager to act.  Attention moves to the question, "How will we do it?"  this stage occurs at the bottom of the "V" in the TPM, the point of the greatest constraint.  This means committing to a specific course of action, making decisions about resources, and being clear about roles.  These are also the indicators of having addressed the "turn".  Remember that the initial stages of team performance involve a good bit of trial-and-error.  Embracing these questions might require backtracking to goals, investing more in trust development, and revisiting initial purpose before you can fully resolve commitment issues."

Keys to when commitment challenges are resolved
- assigned roles
"As your team turns toward implementation everyone will want to be clear about roles and responsibilities. You may have considered these during stage three planning, but now need to commit to what your function, authority, and responsibilities will be in practice.  Role definitions have to be complete enough to cover all the tasks that must be done to accomplish your team goals while minimizing overlaps and role conflicts.  A big part of your job if you are the team leader is to help match goals to competencies, and help people step into roles that will develop their abilities and improve results for the team."

- allocated resources
"In addition to role clarity, your team must deal with another constraint - how to provide for and deploy its limited resources, including time, money, and so forth.  These hard choices usually involve setting aside some useful tasks because the resources are not available to support them.  Indecision in this area breeds confusion and stalls work.  For virtual teams, decisions about tools and communication platforms are essential at this stage.  Teams may have to negotiate with the larger organization to get the kind of tools and support they need.  This is why the TPM intersects the organization "platform" at this stage."

- decision made
"Finally, a team needs to get clear about how members will handle decision making.  Will authority be shared?  How will you stay in touch with one another?  Who can spend what funds?  In a dynamic work environment where plans can change frequently, decision about course corrections are common.  Thinking through in advance how these will be handled moves the team's focus more productively toward implementation and high performance."

Challenges at stage 4, members may show...
- dependence
- resistance

Implementation - Who does what, when, where?
"Implementation involves scheduling and sequencing work over time.  The key question is "Who does what, when, and where?"  A visible schedule, strategy, and / or process liberates the team to move into action confidently.  Conflicts and confusion arise when there is commitment but no clear way forward."

Keys to when Implementation challenges are resolved:
 - clear processes
 - alignment
 - disciplined execution

Team's blocked at stage 5, member may show...
- Conflict
- Nonalignment
- missed deadlines

High Performance - WOW!
"High performance is a WOW state, as a team masters its processes and begins to experience the ability to change goals as well as achieve them.  You can feel when it happens and observe its effects, buy not necessarily control it.  Teams achieve a flow state when trust is high and people have mastered their roles.  In a state of high performance, boundaries and individual limits soften, everything moves together, and everyone responds as if they are part of the whole.  The indicators of that having happened are spontaneous interaction, synergy, and a team that is surpassing their expectation on results.  WOW symbolizes how high performance teams transcend rational processes by working with all the human faculties - spirt, soul, mind, and body."

keys to when High Performance challenges are resolved:
- spontaneous Interaction
- synergy
- surpassing results

When a team is blocked at stage 6, members may show...
- Overload
- Disharmony

Renewal - Why continue?
"Over time the conditions that initially set your team in motion will change.  High Performances is demanding.  Don't be surprised if people ask, "Why continue?"  this key question reminds us that team performance is an ongoing process, and must be renewed by returning to Stage 1 and reassessing if the work is still needed, worthwhile, and has some personal value and meaning.  Spending time on renewal puts your team back in touch with meaning and purpose and refreshes everyone's commitment to keep going.  It also includes learning from what you have accomplished, and building a repertoire of best practices for the next journey on this or other teams.  If your team's work is completed, Renewal is the time to wrap things up, freeing members to move on to new challenges."

Keys to when renewal challenges are resolved:
- recognition and celebration
- managing change
- staying power

When team's are blocked at stage 7, members may show...
- boredom
- burnout


This is just a taste of the awesomeness of Sibbet's book on visualizations and exercises to build great teams.  Want to know more - read the book.  You will learn lots about how team move forward and backward toward performance.  And the exercises to work with teams to help them share their understand of where they are, where they are going and what might set them back are very well explained.

Reference:  Visual Teams - Graphic tools for commitment, innovation, & high performance by David Sibbet.

See Also:

Jay W. Vogt of Peoplesworth explains the Drexler Sibbet Model of team building and how it can result in a positive outcome. YouTube
Management 3.0 Workbook
7 levels of Delegation exercise

Sibbet discusses the origins of the TPM - SketchTalk

Categories: Blogs

Develop Agility for business reasons (success factor 1 of 6)

Bruno Collet - Agility and Governance - Thu, 08/04/2016 - 15:56

If your company is making shoes, then the Agile transformation should improve selling or making shoes. As Peter Drucker once said, "companies don't make money, they make shoes." At all times you must be able to provide an articulate answer the question "how does Agility improve our business?".

"If your company is making shoes, then the Agile transformation should improve selling or making shoes."
Too often the Agile transformation is initiated for fuzzy reasons not really connected with business imperatives. Sometimes we want to "do Agile" just because the company next-door is doing it. On other occasions the need for Agility only addresses a local issue such as "we must deliver this project faster" and fails to connect to concrete business reasons. Obviously, if it is disconnected from business reasons then it has little chance to impact the business in a lasting way, which should be the goal of any transformation.

Consider this good example of the need for Agility inspired by one of my clients: "Our growth is declining by 5% per year because our banking products and channels are not attractive to growing customer segments such as millennials. We have shifted at strategic level but execution does not follow fast enough. We still have tedious annual budgeting, big projects for which we want to understand everything upfront, and rigid governance consisting in several committees involved in micro decisions. Our ability to deliver value fast and pivot is very limited."

You can see that the person has given serious thought about why Agility matters for the organization and how it could address real business challenges. We should strive to reach this kind of statement from day one in order to set the transformation wheel in motion.

How do we achieve this concretely?
Have the Agile transformation expert interview key stakeholders to understand why agility matters for them, what is their perception of Agility, and what is their sense of urgency. The interview process will also help establish trust between the Agile transformation expert and key stakeholders.

Design a simple visual connecting agile capabilities with business challenges. This visual also helps define what Agility means for the organization. Indeed although Agile puts forward a common set of principles, context is king and Agility should always be defined within a context. In particular, by explicitly linking Agility with business challenges, we avoid the typical pitfall that stakeholders believe Agility is limited to IT teams doing Scrum. Below is an example for a Telecom organization, based on Agility Board's four A's framework. (full disclosure: Bruno Collet is Agility Board partner)

Then have the Agile transformation expert run a workshop to present findings - which are but hypotheses at this point - and elicit a shared vision, sense of purpose and urgency with key stakeholders.

Grounding the Agile transformation in compelling business reasons creates awareness and desire to transform, which incidentally are the two first steps of the ADKAR model (awareness, desire, knowledge, ability, reinforcement).

What could happen if we don't do this at the start?
Stakeholders will have different perceptions of the business situation (awareness), vastly diverging views on Agility (from Scrum to strategic agility and everything in-between), and varying degrees of desire to take action (from "looks interesting, we should think about it someday" to "we must do it now, we're already late"). As a consequence, the transformation will probably not hold or will be severely downsized to the point of not being transformational anymore. Remember that in a system made of interconnected people, the pace and depth of change will usually be set by the slowest, least committed among key stakeholders.

Next: Apply the Agile transformation to real challenges, immediately (success factor 2 of 6)
The 6 key success factors to start an Agile transformation the right way
Categories: Blogs

Strategies for Managing Interruptions…for Reluctant Scrum Teams

Agile Tools - Thu, 08/04/2016 - 04:29


Stop me if you have heard this before. No, really, please stop me. So there I am working to get a team launched using Scrum. They’re good folks, but frankly, they’re just doing what the boss said.

“We’re using Scrum. Tom is going to show you the ropes and get you started.”
“Right boss.”
“Training room down the hall on the right. 9:00AM sharp.”
“Got it boss.”

And so a rather wary-eyed crew shows up the next morning. As they sidle into the room we eye each other cautiously from across the conference table. I’ll admit it: I’m not feeling so hot. Combine all the glories of travel with a night in a Motel 6 and it makes a mean recipe for a mean trainer. I’m trying to guess if they are feeling as lousy as I am. Hard to tell. Maybe they always breathe through their mouths like that. I can already tell this is going to be a challenge.

So this is the part of the morning where I introduce them to ‘Satan’. No, it’s not what you think. Satan is what I call my trusty 300 page powerpoint deck that I use to break the will of my students and introduce them to the glories of Agile development. Here, have some pipe cleaners to play with while I’m talking. You can make a tiny little gun out of them and try to blow your own brains out before I finish these slides. Don’t say I don’t know how to have a good time in a meeting. Now where were we? Oh yes, here we go, slide 1…

Fifty shaky, sweaty minutes later (Dammit, where’s the coffee?), and the room full of 9 adult men is starting to look like something out of Glen Gary Glen Ross: The best thing these guys are going to get is a set of steak knives. The mood is getting ugly. We’ve just gotten to the part where I tell them that they are now part of a committed team. I can see their eyebrows shoot toward their hairlines when I say it. That’s right Judith, you only work for THIS team now. Nobody else.

The place immediately lit up like someone spitting cheap vodka on a campfire. In hindsight, I really should have seen this coming: a lot of these guys are from the operations team (for those of you new to software, operations is the software equivalent of the galley where we keep our slaves). Those guys work hard. Like breaking rocks hard. They’re interrupted so frequently, they’ll eventually get a new variety of Attention Deficit Disorder named after them. It’s merciless. If you don’t like it, no problem, we’ll find a replacement just like you.

So there I was telling them they have nothing to worry about, just tell the old boss that they’re Agile now. Yeah, tell ‘em Tom sent you. Agile teams are dedicated and can’t be pulled apart just for firefighting. Here I was, telling them that the nightmare was going to end. You’d think they’d thank me! Perhaps it was the hangover, but I just wasn’t picking up on the mood in the room with my usually alacrity. Note to self: next time stick with tequila.

So I was told, in no uncertain terms, that they fully expected to get pulled off of their work during the sprint for any number of unanticipated reasons. That was just the way things worked at this company. Managers felt perfectly entitled to pull you off a team any time they liked (after all, you were still “theirs”). This was the status quo here. It wasn’t unusual to have people who were over allocated by several hundred percent!

That’s right, it’s not just my poor alcohol addled recollection failing. These folks were expected to work simultaneously on 5 or more projects at any given time. Ouch! As I tried to tell them that was crazy, I could hear an all-too-familiar edge of hysteria creeping into their voices. Right then, it hit me like a pole axe between the eyes: I was explaining this to the wrong people! Finally sensing the disaster I was in danger of perpetuating, I did the only the only sensible thing one can do in a situation like this and beat a hasty retreat. That’s right, I needed to run away. Time for a distraction.

“Hey! I Know what to do! Let’s play a game!”
You see, when you need to distract a class and bail yourself out of a tight spot, nothing works quite as well as a game. As the team struggled to comprehend the arcane rules I’d just arbitrarily made up (I swear to God there was a beer game just like this in college) I racked my brains for ways to help these poor bastards out.

I was only confident of two things:

1) Talking to the managers would serve little or no useful purpose. Besides, I’d done that already. Just between you, me, and Machiavelli: it’s a total waste of breath. Most managers (and I speak here from experience) are normal, perfectly well meaning people, who have had the learning centers of their brains completely erased by the non-stop firefighting, infighting, and general chaos of their jobs. The average manager’s brain is like the surface of a cheap George Foreman grill: nothing sticks. But don’t despair quite yet, because there is a ray of hope…

2) Managers can be trained. I know: I used to train rats.

You see if they won’t willingly change their behavior, you can always change your own behavior. This is key to understanding change and cultures. Something has to change if you are going successfully introduce a new process (wow, that’s so utterly obvious I just got a sharp pain between the eyes). The bad news is change is hard – wicked hard. I think need a drink just contemplating change sometimes (I guess that makes me either a change agent or an alcoholic). But rather than obsessing on how to change the other guy, focus on changing yourself. Then you let them figure out how to react.

Re-energized, I finished the “Intro to Satan” for the day, kicked them out of the office, and went to do some thinking. I needed some inspiration.

Fortunately the bar wasn’t far away. Using that little epiphany as a starting point, I sat down and started writing a list of all the things that the team could do to help deal with their interrupting managers on the back of a beer coaster. It went a little bit like this (I started with the hardest one first):

  1. Say ‘No’: Yeah, I can’t say it either. It takes some practice. Repeat after me: NNNNnnn…uh,nnnuhhhhh, Nuuh, Nuuuoooo, Noo! Come on now, I know you can do it!
  2. Use Buffers: Use a time honored way of protecting schedules and buffer the heck out of yours. As soon as they figure out what you are doing, they’ll leave you alone. Well, if they are smart they will. Your mileage may vary.
  3. Use your Sheepdog: You have this wonderful creature armed with a mouthful of sharp teeth that lives to protect you from outside influence: the scrum master. Use ‘em.
  4. Cover your Buddies: If your team mate is in danger of getting nabbed, stick up for them! A chorus of “No!” is much more powerful than a piteous lone ‘no…’
  5. Escalate: Hey, use the bureaucracy for what its really good for: aggravating others.
  6. Abnormal Sprint Termination: this is a curious bit of scrum geekery that you don’t see very often, but it could work. Threaten sprint termination. Better yet, let the scrum master do it. They LOVE that kind of thing. Makes their whole day.
  7. Automate, Automate, Automate: Did I mention automate?
  8. “Tom said…” That’s right – blame it on me! It’s my fault. I admit it. I told you to say “No.” So go ahead, fire me.
  9. Working Agreement: OK, admittedly this is the most tepid offering of the bunch. But it could work, right? Put together some sort of working agreement with the managers in question. Of course that would involve communication and cooperation, and I hate the idea already. But it might work.
  10. illegible…note to self: never rest your beer on your work.

So here’s the bottom line:
Sometimes if your managers won’t change their behavior (and frankly, why should they?) then you may need to change your own behavior. You’ve got to give ‘em a reason to change. That’s what these suggestions provide – small changes in your behavior that will require changes in the organizational response.

Filed under: Uncategorized
Categories: Blogs

The 6 key success factors to start an Agile transformation the right way

Bruno Collet - Agility and Governance - Wed, 08/03/2016 - 15:52
In this series of posts we'll explore the 6 top success factors to start an Agile transformation the right way: understand why they matter, how to tackle them, and the pitfalls to avoid.

One of the main reasons Agile transformations fall short of expectations is because conditions for success are not met at the beginning. Although it's possible to adjust after starting, these success factors are so fundamental that they usually have to be present early on. Beyond knowing what has to be done, it requires courage and determination to actually do what it takes to start the Agile transformation on a solid foundation.

  1. Develop Agility for business reasons
  2. Apply the Agile transformation to real challenges, immediately
  3. Scope the Agile transformation consistently with behaviors to change
  4. Develop Agile leadership
  5. Initiate the Agile transformation as an official investment
  6. Steer the Agile transformation at executive level
Categories: Blogs

The 6 key success factors to start an Agile transformation the right way

Bruno Collet - Agility and Governance - Wed, 08/03/2016 - 15:52
In this series of posts we'll explore the 6 top success factors to start an Agile transformation the right way: understand why they matter, how to tackle them, and the pitfalls to avoid.

One of the main reasons Agile transformations fall short of expectations is because conditions for success are not met at the beginning. Although it's possible to adjust after starting, these success factors are so fundamental that they usually have to be present early on. Beyond knowing what has to be done, it requires courage and determination to actually do what it takes to start the Agile transformation on a solid foundation.

  1. Develop Agility for business reasons
  2. Apply the Agile transformation to real challenges, immediately
  3. Set organizational scope consistently with behaviors to change
  4. Change leadership behaviors
  5. Initiate the Agile transformation as an official investment
  6. Steer the Agile transformation at executive level
Categories: Blogs

Destroy The 60 Second HTTP Request

Derick Bailey - new ThoughtStream - Wed, 08/03/2016 - 13:30

How long should a “Contact Me” form take, on a website?

You type in your message, click the “send” button and …

10 seconds … 30 seconds …

… a full minute, just to send an email?!


Sure, there are a lot of steps to something as simple as sending an email.

There’s the web server handling the request, configuration for the SMTP server, opening a connection from your server to the SMTP server and handle errors for that connection.

The email needs to be formatted, and you have to send the email and wait for a response to make sure it was sent.

All of this happens every time you send an email, too. No wonder it can take thirty seconds to a minute to do something that should be simple!

But here’s the real killer… as frustrating as it is for you, a developer that knows these things, it is 100x more frustrating for the average user that expects your website to work instantly.

No one wants to stick around for 30 seconds or more.

And when you look at the largest, most popular and most used sites around, none of them make you wait around like that.

Have you ever created a new git repository on GitHub?

Perhaps you’ve paid for something with PayPal or on Amazon?

These websites and systems do not process your request in real time. They use message brokers, queues and background processing systems. They respond to you almost immediately while doing the actual work in the background.

Your web server should not be doing the heavy lifting.

Like Amazon, Github, PayPal and so many other services, your application design should use background processing for any real heavy lifting.

I’m not talking about simple select statements from a database, or even basic inserts when you’re just dealing with CRUD data, necessarily.

But any time you have real work to do where there may be a failure from a network or other external resource, you should consider a messaging system like RabbitMQ.

Any time you have work that would significantly delay the response from the web server; any time you have to handle failure with retries; any time you need to know that work has been requested and receive status updates…

It may be a network resource, such as an SMTP service. Or perhaps is an image manipulation and processing system. Webhooks are another great place where your work should be pushed into the background.

There are countless opportunities around you, where you can improve the architecture, performance and maintainability of your software system.

And these are all cases where RabbitMQ and the patterns that it brings to the table, will greatly improve your application architecture and design.

It may seem overwhelming when you first look at messaging servers, though. And that’s understandable.

But you may not realize this:

You’re already working with messaging patterns and message queues. Every day.

If you have ever sent an XHR / AJAX request from a browser, that’s an asynchronous messaging pattern.

Open your email client of choice – there’s a queuing system.

Ask a coffee shop employee to make your favorite drink, and dozens of messages will be sent between the employees and other systems to fulfill your request.

Stand in line at fast food restaurant or a bank, and you’re in another a queue.

You’re already taking advantage of the way the real world works with messages, brokers and queues.

Isn’t it about time your application architecture took advantage of this, as well?

Join my mailing list, below. I’ll send you more information on RabbitMQ and how it can improve your application architecture with messaging patterns.

You’ll hear about success in spite of failed and buggy code, and find resources on how to get started and work effectively with RabbitMQ.

Categories: Blogs

Introducing a Simple Portfolio Planning Method

Agile Product Owner - Wed, 08/03/2016 - 00:37

The SAFe Portfolio Level has been evolving rapidly.  Today, it incorporates a Lean-Agile budgeting model, a Kanban system for business and enabler epics, guidance for coordinating multiple Value Streams, connection to the enterprise business strategy, and more. But outside of the portfolio Kanban system, it hasn’t provided much actual guidance on planning for the implementation of epics. We’d like to close that gap bit with an incremental step that advances the toolset for the SAFe Portfolio. Please check out the new guidance article here.

The method is based on balancing two important concerns for Portfolio work: a) consistency of work across Value Streams and b) capacity bottlenecks in the Portfolio. It utilizes a simple view that incorporates the two perspectives, as the figure below suggests.

Figure 4. A number of Epics loaded into the plan

The method enhances the visibility into the two factors and allows the Portfolio planners to reason about the potential portfolio roadmap. There is an important caution though. One must remember that SAFe planning at the Portfolio Level can only produce input to Value Streams. The tool cannot and should not be used to commit the teams to a certain course of action; in SAFe, only teams themselves can ultimately commit to a certain scope of work. They achieve that via PI Planning. The method above aims at pre-planning and forecasting of portfolio work, rather than offering concrete expectations in terms of what should be delivered and when.

Where does this tool fit into SAFe? Clearly, as part of the Portfolio Kanban system. There, Epics get decomposed into Capabilities which are, in turn, distributed across the Portfolio Value Streams. This is where the tool turns out to be very useful. We hope to integrate this content there at some point. But of course, the same model can be used for Value Stream planing as well.

Well, this post is getting to be as long as the article, so enough said. Please check out the article,  and as always, provide feedback in the comments below.

-Alex and the rest of the Framework Team.


Categories: Blogs