Category Archives: Introduction To Agile

How HR Can Save or Destroy Agile

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

“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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Three Links For Agile Product Development

Learn more about transforming people, process and culture with the Real Agility Program
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.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

David Sabine: What Real Agility Means To Me

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

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

80 Agile Links Right Here on Agile Advice!

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

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


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Advice: Start Executing With Little Planning

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

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Obstacles to Enterprise Agility

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

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.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: The Human Side of Agile

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

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

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!

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Yes, There Are Agile Best Practices

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

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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail