Category Archives: Introduction To Agile

Agile Blog: Scrum vs Open Agile vs Kanban (Visual Summary)

Welcome Agilist…whist we focus on ‘Being’ Agile, ‘Doing’ Agile goes hand in hand towards achieving a common goal…here is a quick visual comparative summary of 3 closely related but unique systems (Scrum, OpenAgile and Kanban) to get started…

  1. Origin
  2. Domain Application
  3. Time Availability for Change
  4. Roles
  5. Workflow
  6. Frequency

Ref:

https://www.scrum.org

http://www.openagile.com/

https://leankanban.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

A Litmus Test for Agility

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

How HR Can Save or Destroy Agile

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.


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

Three Links For Agile Product Development

Last week, conversations in the Scrum Facebook Group clamoured around the topic of Agile Product Development and Agile Project Development or Management.
To be honest, when I posed a question on the topic I had a hint of its significance but did not have even a glimpse of the depth of this can of worms until many more conversations, online and offline, and research on websites and YouTube on the topic.
One respected coach said to me that there may be no bigger issue than this in the Agile industry. Well then, let’s explore it a little bit.
Here I’m including three links which Facebook group members recommended. I hope these links may also be useful to other new Product Owners who are grappling with the concept of “no projects” in their work environments.
This is undoubtedly by far the very best Product Owner video I’ve seen to date. It’s just 15 minutes long. The speaker is clear and easy-to-listen to. The graphics are descriptive and simple despite representing complex ideas and systems. I came away from this video with a much more thorough and concrete understanding of the role of Product Owner.
This book is recommended by a fellow Scrum enthusiast. Amazon describes it in this way,” In Agile Product Management with Scrum, leading Scrum consultant Roman Pichler uses real-world examples to demonstrate how product owners can create successful products with Scrum. He describes a broad range of agile product management practices, including making agile product discovery work, taking advantage of emergent requirements, creating the minimal marketable product, leveraging early customer feedback, and working closely with the development team.
While I haven’t had the chance to read it yet myself, I find it reassuring that a renowned author addresses this important topic and offers his valuable insight into the conversation around Product Owner and Project Manager.
agile-team-room-example
On September 09, 2016 a blog post about User stories addressed this very relevant question. The first line states, “User stories can be considered the basic units of work in organisations using an agile approach to product development.” I found this post and this website very useful in understanding the importance of user stories and how these fundamentally shift work process around delivery of value to customers.

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

David Sabine: What Real Agility Means To Me

Image

“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future,” David Sabine

My name is David Sabine. I’m a Real Agility Coach and have been thinking about what Real Agility means to me.

My introduction to Real Agility began in 2007 when the CTO of the college I was working at in Fort McMurray, Alberta brought in Mishkin Berteig as a third party consultant. Back then, I was a software developer and what I experienced then is still true today. The value of bringing in a third party to solve business challenges is immeasurable.

Time and time again, as I have been involved with companies, either in a training or a consulting capacity, I have found that a third party presence provides or creates a break-through. The purpose is not that I go to a company as a consultant and I bring my new ideas, as though I am the only one with new ideas.  What happens instead is that I visit a company and my presence, as a coach, opens the door for the internal staff to explore their own new thoughts, or concepts or possible solutions. So the ideas that are already in the company are just allowed to blossom a little bit in the presence of a third party,because this third party allows or creates a sense of permission, a sense of autonomy for those staff. They’ve been invited to explore concepts and they’ve been invited to think through their business problems from a different perspective and I am there just to reflect what they already have or what they already know.

That occurred when Mishkin Berteig visited the college in 2007, and that occurs every time I go and visit a company for training or consulting.

To really understand what Real Agility means to me, I’d like to tell you about how I came to software development in the first place beginning back in 1993 when I was starting university and was a freelance musician.

I had two passions at the time: the pursuit of music and the logic of programming. My computer tended to pay the bills, more so than being a freelance musician, so as a career path I guess I was drawn to software development and started to build my own products early on in 1996-1997. I was writing software for small business clients with the aim to eventually build a product on my own and release it for sale worldwide.

In 2000, I started to develop a product with a friend of mine. In 2001 we released it to other developers in the world. Our first sale of that product was in Belgium and for the next few years it sold worldwide. We had about 2000 websites that were using our product and it was translated into seven different languages by the community of users. It provided my friend and I with a reasonable income and a great opportunity. It was fun!

In 2006, I realized that my own growth as a computer scientist required working with others beyond this friend, to work in a team, in fact. I moved to Northern Alberta and worked in IT department for a college. As I mentioned, in 2007, the CTO, brought in Mishkin Berteig to provide us with a 3-day training course on Scrum. Quite immediately I loved it because I could see how it would provide us with a lot of opportunity to solve problems we were facing in an IT department and, secondly, it just seemed like a more human way to work. I was reflecting on all of these periods I had had as a musician, working with other musicians, and it just seemed like a better way to approach the creative endeavor than other project management methods that were in play at the time.

Since that time, I’ve been practicing them in a variety of settings and I’m more convinced now than ever that the Agile Manifesto provides us with a great solution space as we respond to business challenges. Recently I’ve decided not to be a developer or product owner but have decided to join Berteig full time and train and coach other teams.

So that’s the story of my personal evolution. My personal journey.

Looking back on that training I can see how I felt immediately that Real Agility was an alternative way of doing things.

I studied music since I was a child and music has always been a huge part of my life,and as a musician, one becomes aware of or familiar with continuous improvement. This is the same concept found in Real Agility. But with music it’s incremental, tiny, tiny increments of improvement over time. We respond to an audience. We respond in real time to our fellow musicians. We are always taking in input and that informs our performance of the music. As musicians, we spend a lot of personal time developing our craft. We spend significant time in performance so we can receive the audience feedback.

What I mean to say is that musicians are excellent examples of high performance teams and are excellent examples of creative excellence, who understand tactical excellence and what it means to get there.

When I joined Software development in a large, bureaucratic institution – the college – it was anything but natural for me. At that time, I was more than just a software developer. I was systems analyst, database admin and a variety of positions or roles. It just felt like an industrialized, mechanical environment where people were expected to behave as interchangeable units of skill. Work was expected to get done in the prescribed procedure. And decisions were expected only to be made by the smartest or the highest paid few and if you weren’t of that ilk, you were not expected to behave autonomously. You were expected to be just part of the machine and it felt very inhuman, as most people feel as a part of a large hierarchical bureaucracy.

When Mishkin facilitated the Certified Scrum Master training course in 2007, it just blew all those doors open. It reminded me that we can approach our work the way I had naturally approached it, as a creative individual who is capable of learning and wants to receive immediate feedback from audience or user, and who can make autonomous decisions about how to apply that feedback into the continuous development of software and systems and large infrastructure.

These business challenges are pretty common. They are delayed projects or projects that that blow the budget, or where a group of people are assigned to the project and they can’t possibly complete the scope of work in the time given. Or staff are demoralized, and how that expands through enterprises. There are many examples. The college where I was working suffered all of the most common issues and the one that hurt me the most or I felt the most was attrition. Dis-engaged staff. The reason for it was simple. The college had not presented with them a purpose or opportunity to be masterful. The extrinsic motivators, salaries and such, were just enough to keep people for a little while and then they would leave. And so the college at the time was experiencing attrition of 35-40% per year and that’s what I meant by inhuman.

“These Real Agility methods presented a change. In fact, people become centric to the purpose!”

When I read the Agile Manifesto I think that it provides us with solutions, and so if our current business problem or business circumstance is that we have disengaged staff who aren’t very productive and aren’t getting along well, then the Agile Manifesto reminds us that perhaps business people and developers can work daily throughout the project together. They can have continual interaction, and then individuals and their interactions become more valuable than the process and the organizational tools that have been put in their way. It reminds us that people should be allowed to work at a sustainable pace. We should build projects around motivated individuals. And that poses questions about how to do those things. What does it mean to be motivated, and how do we build projects around motivated people?

So Agile Manifesto presents us with some challenges, as a mental process, and then when we work through that we understand how it can inform good decisions about how to solve business problems.

Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future.”

In other words, Agility means being nimble, the ability to adapt to current circumstance, but more than that, Real Agility means that we should approach our work with the intention that we stay light-weight so that when our circumstances change we can adapt without a lot of inertial resistance. So there’s two components there. One is being able to adapt quickly, and being aware of present circumstance but the other is that we don’t want to take on weight and institutional mass, because that’s inertia, the status quo.


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

80 Agile Links Right Here on Agile Advice!

Did you know the “Agile Resources” page on this blog has 80 links to valuable Agile Resources compiled by Mishkin Berteig?

The page contains a number of links to recommended web sites, books or tools relating to Agile Work. It’s updated from time-to-time and as this is done, announcements are posted on the Agile Advice blog. As such, this page will always be “under construction”. If you have links to suggest, Mishkin will examine them for consideration.

Please feel free to post suggestions.

We’d love to read your comments and ideas!

A LIST OF 80 INCREDIBLE RESOURCES

Introductory Material:

Agile Axioms
Agile Manifesto
The OpenAgile Primer
OpenAgile Resources and Presentations – English & Chinese available
Agile Work Cheat Sheets and White Papers – Berteig Consulting Inc. [pdf]

Agile Software Focus:

Extreme Programming
Methods and Tools
The Scrum Primer [PDF]
A Scrum Primer – Report from Yahoo! [PDF]
Scrum and XP from the Trenches
Scrum and Kanban
Control Chaos – Ken Schwaber and The Scrum Methodology
Agile Software Development by Alistair Cockburn
Agile vs. Lean – Thad Scheer
No Silver Bullet by Frederick Brooks
Agile Planet – agile blog aggregator
Buildix – agile software dev tools on a CD
Agile Forums
Implementing Scrum

Project Management:

Agile Project Management with Scrum – Ken Schwaber
Project Management Institute
Agile Project Management Yahoo! Group
Burndown and Burnup Charts
Huge List of Software Project Management resources
Scrum Alliance – Agile Project Management and Training
Project Management Resources – by Michael Greer. I don’t agree with everything on this site, but if you are looking for traditional PM stuff this is a good place to go.

Lean and Theory of Constraints:

Lean Software Development – Mary and Tom Poppendieck
Evolving Excellence – by Kevin Meyer, Bill Waddell, Dan Markovitz NEW!
Theory of Constraints – Eliyahu Goldratt
Agile Work for Flow Projects – Mishkin Berteig
The Toyota Production System
Practice Without Principles – TPS Without the Toyota Way – Victor Szalvay
Agile Work Uses Lean Thinking – Whitepaper [pdf] by Mishkin Berteig

Management:

Agile Management Yahoo! Group
Slow Leadership – the opposite of Agile?
Adaptive Management – Jeffrey Phillips

Adult Education:

The Self-Educative, Narrative and Metaphorical Faculties of the Soul – Alexei Berteig (pdf)
Infed

Team Building:

The Wisdom of Teams: Creating the High-Performance Organization
Retrospectives
Retrospective Patterns by William Wake
How to Win Friends & Influence People – Dale Carnegie

Community Development:

Corporate Culture:

Catastrophic Organizational Change – Tobias Mayer
The Corporate Culture Survival Guide – Edgar H. Schein
Good to Great (fastcompany article) – Jim Collins

Agile Services:

Berteig Consulting – Agile Work Coaching, Training and Consulting
CC Pace
Digital Focus
Israfil Consulting Services Corporation
Scrum Alliance
Tobias Mayer
David Chilcott
Joe Little
Michael Vizdos

Agile in Other Domains:

Extreme Project Management for Architects

Experiences and Stories of Applying Agile in Other Domains:

Agile Documentary Video Project
Agile Publishing


The following sections of material are based on the Agile Work Cheat Sheet.

We are Creators

Reality is Perceived

An Introduction to General Systems Thinking by Gerald M. Weinberg

Change is Natural

About “Resistance” by Dale H. Emery

Trust is the Foundation

Agile or Not Agile?
Trust and Small Groups

Empower the Team

Launching an Agile Team – A Manager’s Howto Guide

Amplify Learning

Abe Lincoln’s Productivity Secret – a nice little bit about being properly prepared (although caution should be taken not to over-prepare!)

Eliminate Waste

Self-Organizing Team

Variations on the Daily Standup – Rachel Davies
Scrum from Hell – William Wake
Team Formation Stages – Forming Storming Norming Performing

Iterative Delivery

Are Iterations Hazardous to Your Project? – Alistair Cockburn

Adaptive Planning

Maximize Communication

Edward Tufte’s web site with lots of great info about the visual display of information
Human Tools for effective communication
Eight Barriers to Effective Listening
Facilitation Skills [pdf]

Test-Driven Work

The Qualities of an Ideal Test

Appropriate Metrics

Appropriate Agile Measurement White Paper (pdf)

Removing Obstacles

The Art of Obstacle Removal

Intros and Summaries

The Seven Core Practices of Agile 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 Advice: Start Executing With Little Planning

Agile Planning

“Start executing and worry less about planning.” QA Consultant

This statement appeared on a recent feedback form after a BERTEIG learning event. It summarized a Quality Assurance Consultant’s learning from the CSM training they attended.

This statement so accurately summarizes one of the key principles of agile methodology which is to do minimal planning and review often. It doesn’t mean “No Planning” it just means different kinds of planning and the willingness to jump quickly into action.

Mishkin published an article on this topic in 2015  and it is re-posted here now because it is still so relevant today.

 

Agile Planning in a Nutshell

Mishkin Berteig 201504 white background - 640w

 

 

 

By Mishkin Berteig

Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning PokerThe Bucket SystemDot VotingT-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimation and planning.


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

Article Review: Obstacles to Enterprise Agility

Michael James, Certified Scrum Trainer, shares an article listing his understanding of the key obstacles to Enterprise Agility which can be found in the link on this site. He lists seven obstacles and the most meaningful seems to be number seven, staying committed to the transformation. Each individual on the team must be committed to the transformation, to be willing to endure the “storming period” which a team goes through when they are learning to work together in an agile way.

When they stay committed, as Michael James describes, then they are well on their way to adapting the agile methodologies which will allow for high-performing teams.

Experts in the field will be well aware of this concept by now, but for beginners it is worth breaking down into bits. Every conversation about agility in an organization ultimately involves a whole team changing – and not just one or two members by the way — so that an entirely new and more productive environment can allow for more efficient delivery of product.

Have you seen an agile team go through storming? What was it like? Did you see positives come out of it? Please describe your experiences 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

Link: The Human Side of Agile

Scrum of Scrum photo

On the blog “Fragile” the author writes about the human side of Agile.  The author, who does not name themself anywhere on the blog, criticizes the agile movement for not giving more time to the issue around management.

Here are some of the key arguments:

  • not enough care is taken over the distinction between project and line management
  • almost all agile implementation failures could be traced back to management’s reluctance or failure to engage
  • practical guidance is needed for an agile team leader to describe how they might incorporate these ideas into their role.

The author also notes that an anecdote they wrote was included in a recent book. It basically describes a way to make the most of an environment even if management is not providing funding or space to support agile implementation.

Here is the antidote:

It may not always be possible to create the perfect working environment, however it is important to make the most of what is available. My team were looking to map their work flow using a white board and sticky notes. Unfortunately we were situated in the middle of an open plan office without access to walls, nor did we have the necessary space for a for a free standing white board. In the end we bought a roll of white board sheeting and applied it to a nearby structural pillar. Work items flowed from top to bottom and space was tight, but it served our purpose and is still in use years later.


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

What Do We Mean By Welcoming Complexity?

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!

 

 


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

Yes, There Are Agile Best Practices

Scrum of Scrum photo

I recently read an article by Jason Little entitled, “Yes, There are Agile Best Practices.”

He acknowledges that the Agile community hates the term but continues to assert that, “it’s more about the implementation of the practices as opposed to the practices themselves. [For example] Having Daily Standups, Retrospectives and Demos/Sprint Reviews are non-negotiable starting points for any team new to Agile. You don’t necessarily need to co-locate, or strip everyone of their titles, or even be Agile. The easiest way to get started when you’re new is to do these 3 best practices. How and when you do them is what will need to be adjusted over time, but not doing these 3 best practices means there’s not much point in getting started with Agile in the first place.”

He has a good point. No sense in doing best practices just for the sake of saying they are done. It’s pointless.

Any Agile team would want to include these 3 practices into their routine, otherwise they are not really considered an Agile team.

His article was informative and I enjoyed the read.


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