Let’s begin by agreeing that the quest for success starts with the right approach to support project delivery.
As a practitioner in the project, program & portfolio management space for many years now, I have seen different delivery approaches work for different organizations based on project characteristics and organizational needs. Each project need will have a spot on the continuum, from the predictive waterfall approach to an Agile approach.
Meanwhile most of the practitioners I interact with seem to have chosen a side – there are some strong believers of waterfall that stresses meticulous planning and a sequential delivery approach, while others are strong believers of less process heavy, iterative delivery approaches.
I, personally, beg to differ. I believe that both of these approaches have their own strengths and weakness and there can be successful co-existence between these methodologies. Being mostly surrounded by waterfall experts, I have seen a huge gap between traditional project management perspectives and the newer, more Agile approaches.
Most of these gaps stem from limited knowledge on the subject from the opposite side. Specifically, here are some key disconnects that I have encountered over the years
An Agile approach is the extreme opposite of Waterfall approach
Even in the most Agile centric environment, many of the Waterfall project management principles are valid even if applied in a different context. These principles might not fall neatly into some of the typical knowledge areas of traditional approaches, such as scope, time and cost management – but there is still a need for striking the right balance between planning, control and agility. All project life cycles include a planning element. What differentiates the life cycle is how much planning is done and when.
For instance, risk management processes, in traditional waterfall project management, are implemented to control & monitor risks. An Agile approach, on the other hand, implements risk management in a broader sense by coaching team members to incorporate risk management principles into the way the work – thereby eliminating some of the risk monitoring aspects found in the waterfall approach. Both approaches have risk management aspects – it is just implemented differently.
Being Agile only impacts the IT departments
Again, not true.
Any methodology (Agile or Waterfall) requires organizational commitment which extends far beyond the IT or Project Management teams. Not to forget, it may require some major shifts in organizational culture to make it work. What makes any delivery approach successful for an organization is the commitment by the organization to make it successful.
It starts with deciding which methodology will be right for the organization; which one will support their current and future goals and which one can bring them closer to meeting their bottom line. It can very well be a hybrid between traditional and contemporary delivery approaches. What needs to follow is the commitment throughout the organization to change their old mindsets, processes & come onboard to support the change.
The point that I am trying to make here is that thinking of any delivery approach as being a silo to a particular department or team is incorrect. It is far broader than that.
You need to make a choice – Agile or Waterfall
Do we really have to? The idea that you either need to follow a methodology by the book – or not at all. is preposterous. The fact is, an organization can choose to design a delivery approach that creates a perfect marriage between plan driven approach and agility which aligns with the organization’s strategy.
Of course, certain changes would call for a traditional waterfall approach, for instance building a house, and some would call out for an Agile approach, for instance building an app to control the temperature of the house. The fact of the matter is that it doesn’t need to be as rigid as some practitioners perceive it to be. The right thing to do is to be focused on delivering a solution in the most efficient way possible rather than being solely hung up a particular methodology and its boundaries.
In conclusion, practitioners from both communities (traditional & Agile) are so focused on promoting the benefits of their own delivery stream that they tend to overlook the idea of co-existence. It doesn’t have to be a black-and-white proposition – it can very well be a mix of the two – you just need to strike the right balance.
I am a strong believer that there is no one right solution for everything and that a peaceful co-existence can exist amongst different perspectives. I also believe that better solutions are yet to come, ones that are not constrained by current boundaries and that are focused on better supporting the diverse and ever-changing demands of the world we live in.
To understand why so many people around the world have adopted Agile as their first and foremost guide to improvement, we must first look at why leadership has been failing us in the first place.
Leadership, in the modern world, has been equated to a highly visible role, a spokesperson whose suave charisma is infectious, and following their mantra is made easy. No one can deny that they are not impressed when a sharply dressed leader bounds onto the stage at a conference and proceeds to use impressive statistics to back up his or her claims that ‘if we just did this, then the world would be a better place’.
Unfortunately, reality is rarely as static as those brief moments of exuberance. The truth is, companies have been built and shaped over many years, sometimes decades. The charismatic hand-gesturing of the modern world leader (especially in technology) does not go far in the grand scheme of things to change an approach that has been ingrained in us. Undoing bad habits and helping people build new habits is hard work.
What purpose then does Agile serve to help us with this task of getting better and why should you, as a leader, care?
Leadership implies leaving a legacy that was stronger than when you first started. The leadership you provide has to be ingrained within the culture of the organization you leave behind. In short, being Agile, thinking in an Agile way allows us to be transparent and honest, learning from our mistakes without fear of retribution and scorn. That in itself is a huge shift in the way we think.
One of the Agile Manifesto principles states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” While the concept is simple, it implies that you, as a leader, need to act in a supporting role. Encourage acts of leadership in others. Don’t focus on the mistakes. Create an environment where work, and even innovation, can happen!
“Culture eats strategy for breakfast”
There probably won’t be a defining moment in a successful project which someone can point to and say: that was the moment where you as a leader made all the difference in a project. But slowly, over several months of sustained support and Agile thinking, you will positively affect the culture of the organization. As the late management guru Peter Drucker said, “Culture eats strategy for breakfast”, implying that no amount of managing of people would be more positive than the intrinsic motivation people have to succeed in their work.
Kiichiro Toyoda, the founder and first president of The Toyota Motor Corporation, created and espoused the Toyota Production System (TPS). In this management philosophy (built from the Lean production perspective), he believed that because people operate the system, the strategy to success has to be a people-oriented system. TPS respects the fact that only the people on the production-line can make the changes necessary for improvement. This is where leadership should focus.
Moreover, the culture of excellence has to become ingrained in the line worker to the extent that ‘good enough’ is no longer a workable philosophy. So what can you do as a leader to make the change happen? The well-known thought leader in business-leadership, John Kotter, writes about the ways that change management can be ‘made-to-stick’. For this article, suffice to say that establishing a need and creating visibility are at the forefront of what he espouses.
Creating transparency allows us to understand the current situation. Only then can we begin to tackle the problems with a frank and consolidated effort. Mistakes will ensue; however in an environment of learning, where mistakes are opportunities for improvement, success will undoubtedly follow.
At BERTEIG, our coaching and consulting approach is to support leadership in this endeavour. Almost every great leader has had the support of a non-judgemental partner to help them achieve more, and we take your success as our success. We believe that the legacy of your company will therefore be in the Agile way that people work, not the antiquated legacy systems in place that hold you back.
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…
“Paratroopers are used for tactical advantage as they can be inserted onto the battlefield from … any location[. This] allows paratroopers to evade emplaced fortifications that exist to prevent an attack from a specific direction”
I believethere are certain analogies between being a Paratrooper and being an Agile Coach or Consultant, including having strategic objectives, a purpose of infiltration, a sense of opposition, and a goal or cause that you believe in.However, I am notasserting that, a) implementing Agility at an organization is a declaration of war, b) Agility is a tactical warfare technique, or, c) being an Agile Coach or Consultant is synonymous to or nearly as dangerous a job as a Paratrooper.
Having said that, depending on the environment an Agile Coach or Consultant may sometimes feel like they are actually entering a corporate or political war zone. They are often viewed as outsiders posing a clear threat. They are often in the minority. They are often dropped in to unfamiliar territory. They often have incomplete or incorrect information. They are often surrounded by opposing forces. They are often made a target, either passively or aggressively. They often start with plans, but what makes them successful is their ability to adapt their plans and react to situations. In other words…be agile!
Like a Paratrooper, a Coach or Consultant is often “parachuted” or “inserted” in to an organization or foreign group with a specific mission. It is often to provide a “tactical advantage” and doing so helps a Coach or Consultant “evade emplaced fortifications [well established norms or strong opposition] that exist”, so they can get the job done from the inside and with less opposition.
A Paratrooper should always enter the field with a good understanding of the landscape, environment and situation. Similarly, a Coach or Consultant should also become familiar with the working environment and culture they are about to interface with. Without critical information both would risk the success of their mission and perhaps more. For a Paratrooper a lack of information could be life threatening, but fortunately the threat is not usually life threatening for organizational change agents. It just might be professionally damaging to their career as well as others and their business.
To that effect, I believe if you are a Coach or Consultant then you should still perform advance research for your intended mission in order for you to be successful, provide value and create an opportunity for learning and improvement. This means you will need to have conversations with both the leadership of their target (organization) and also with the people doing the work. Here’s why.
Leadership (usually the “paying customer” is management in the organization) should have specific and measurable outcomes they want achieved, and it is critically important for you to identify what those are up front and how they are expected to address their business problems. Meanwhile, the employees (usually the workers or teams) are often directly associated with and intimately familiar with the true needs and system issues, so you must also become familiar with their understanding for perspective. Unfortunately, the first battle is often that workers and their leadership do not align on their expectations and outcomes, and without their alignment you have little hope of true customer satisfaction and helping them collectively solve their real business problems.
As such, to manage expectations and increase chances for success it is critically important for a Consultant or Coach to investigate and identify both the needs of the leadership AND the needs of the employees, and then work to align them before any substantial work takes place. The best approach is to have face-to-face conversations with all the leadership and employees but that can take considerable time in a larger organization. So how do you get a realistic pulse of the company without talking to absolutely everyone?
Assess the Team
If the team(s) are using Scrum as a framework then one option is to use a Scrum team assessment tool like Scrum Insight. This tool provides objective coaching advice tailored specifically to a Scrum team as it is designed to detect how aligned the team is to Scrum practices and methods. The free version of this tool provides access to the basic report which contains the team’s overall scores, a “quick win” recommendation that identifies and provides suggestions that can be made to provide the biggest improvement on the team, and a list of support resources. The paid service provides everything in the basic report as well as a detailed Scrum Score Card, a Team Environment Score Card, a relative industry ranking, other education and support resources available for consideration, and it is usually followed up with a personal call to provide you with detailed explanation on the results.
Here is a sample Team Environment Score Card from Scrum Insight. Detailed descriptions for each bar/category are provided in the report:
Here is a sample Quick Win Report from Scrum Insight A more detailed description is provided in the report, and it is tailored to the team’s specific challenges and opportunities.
Another option is to conduct a REALagility assessment – either for a team, a group or an entire organization. The assessment is a 10 minute online survey conducted by every individual, and it is designed to uncover the misalignments between what leaders think and what employees think in an organization. The resulting report reveals the soul of the current culture, and it is grounded in real, actionable data to improve on the problem areas unique to the organization. As a Consultant or Coach these insights can be invaluable in helping you prepare for the engagement, identify opportunities, create alignment, and elicit real, meaningful and sustainable change for the organization.
Here is a sample diagram from a REALagility assessment, showing the relative rankings for an organization around five cultural measures. Detailed descriptions and insights for each cultural score are provided in the report.
In summary, I find it immensely helpful to “arm” myself with information prior to a Coaching or Consulting engagement, and these tools have been pivotal in filling that gap. Having early access to information such as this enables insights that might otherwise not be detected until I am on the ground helping the individuals, teams, and leadership tackle their business problems, which saves time, frustration, and money. An additional advantage with leveraging these electronic evaluations is that they provide an opportunity for people to provide ideas, feelings, agreements or disagreements that they may hesitate to share in a face-to-face interview.
There are certainly other tools that are designed to provide insights and information, but I’ve chosen these two because of my familiarity with them, and because of their effectiveness.
Of course, I would never replace good, valuable conversation with tools or data, but I do find these tools provide additional contextual information that further enables me to ask the right questions and have the right conversations early in an engagement. Finally, these tools can also be used as a benchmark for comparison of progress after a period of time has elapsed, which allows you as a Coach or Consultant to measure and be accountable for success.
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.
There 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?
There 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?
There 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.
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!
If you go on line and type “soft skills” into your browser, you will come up with a plethora of sites. That’s because soft skills are being touted as the most important skill set for any individual in any career. Soft skills are becoming de rigeur in job applications and leadership training of every kind. One might say that there is, in fact, a soft skills revolution occurring in every sector of society.
What is motivating this revolution? Perhaps the more automated our world becomes, we see that our more human characteristics and relationships are needed to balance such a high degree of automation. Perhaps it’s become clear that human characteristics are what drive everything forward in either a positive or negative fashion.
With the advent of the Agile Manifesto (www.agilemanifesto.com) and agile processes permeating business and organizational cultures more and more, people are abandoning the silo mentality and striving to create a more communal environment and team consciousness. Many organizations and businesses are learning that teams rather than individuals are more effective at accomplishing goals.
When a team of people have to work together, there is an expectation that they will all do their best to get a job done. On the other hand, it’s also normal for people on a team to encounter hiccups and even conflicts, whether it’s issues of personality, ego or disagreements of one kind or another. Then there are those team members who do not feel safe to offer their opinion, or those who harbor a prejudice against a certain type of person they may be required to work with.
By putting people together to work alongside each otherday after day, we are creating a potent mix. Human beings are extremely complex and diverse after all. There are volumes written about both the need for and the difficulty of people working and achieving together.
From a recent Insight BTOES newsletter about hiring practices:
“If they’re the best there is in their craft but would prefer to just do their job and be left alone, it isn’t likely they’ll engage in team improvement activities and become a contributing part of the new culture.It’s simply not worth taking on the resistance/non-engagement that you’ll have to deal with until your patience runs out and you’re right back where you started…”
Many corporations now claim that soft skills are the number one priority when hiring, Hard skills can be easily taught but soft skills make the difference whether a person is even teachable and flexible enough for a corporate environment.
This is just the tip of the iceberg, because soft skills have not been the focus of our education systems, and those who have them need continuous practice and improvement. But everyone has the potential to become more empathetic, cooperative, supportive, and respectful.
Whether it’s learning to communicate effectively, or to create a sense of cohesion in a team, there are many pieces that can be put in place to help any team (and its individual parts) be more powerful, effectual and happy.
One very basic ingredient that can make a world of difference to a team’s work is to feel safe. Safety comes with having clear and consistent goals. Team members feel safe to speak his or her mind without fear or judgement, even if their opinion is different from others. A team feels safe to experiment and to succeed or fail. Safety is built on the very essential idea of trust.
Psychologist, author and consultant Harvey Robbins has written extensively about the idea of trust as a key element of any team. He describes trust as follows:
· Trust means setting clear, consistent goals. If people don’t know exactly what they’re supposed to, they will feel set up to fail…
· Trust means being open, fair, and willing to listen. This requires more than making a thoughtful, considerate face. It means listening to the words other people are saying.
· Trust means being decisive… It’s a challenging thing to say, but sometimes it’s better to make any decision – good, bad, or indifferent – than it is to make no decision at all.
· Trust means supporting one another…Your team belong to you, and you belong to them.
· Trust means sharing credit with team members. You are there for them, not vice versa. If you are a glory hog, you are stealing from the team.
· Trust means being sensitive to team members’ needs. You should know what legitimate secondary agendas they may have, and be willing to help them achieve their personal goals.
· Trust means respecting the opinions of others. The worst thing a leader can do is denigrate or dismiss or ignore team members. If they’re no good, move them off the team. But even then you owe them your respect.
· Trust means empowering team members to act. It means trusting that they are up to the challenges that you trained them for…
· Finally, and ultimately, and most difficultly, trust means being willing to suffer… The ordinary leader exposes his people to all the risk. The trusted leader assumes risk himself.
Article Source: http://EzineArticles.com/716760
When a team has clearly articulated goals, it helps build a sense of cohesion, in that every member is aware of what they are working toward. When team members are allowed to work out an action plan toward achieving a goal, this gives everyone a stronger sense of purpose and ownership.
If you’re wondering whether a Team Development workshop would be of benefit to, or is necessary for your business or organization, here are some thoughts from MindTools that can help you decide:
Are there conflicts between certain people that are creating divisions within the team?
Do team members need to get to know one another?
Do some members focus on their own success, and harm the group as a result?
Does poor communication slow the group’s progress?
Do people need to learn how to work together, instead of individually?
Are some members resistant to change, and does this affect the group’s ability to move forward?
Do members of the group need a boost to their morale?”
Everyone has the potential to grow their soft skills. However, a company may not have the resources to help unlock this potential in its employees.
If team development is not part of a company’s culture there may be discomfort in dealing with friction arising from a lack of soft skills. In this case, an external facilitator or coach can be a very helpful resource to guide a work team, using thought-provoking activities and role-playing, to find greater connection and trust amongst themselves, and to address issues with a detached point of view.
Organizing such a workshop for your team does not mean they are not doing well or failing. It means you, the team lead/ manager/ CEO/ HR person, etc, care about your team’s best interests, highest achievements and happiness.
Valerie Senyk is a facilitator for Team Development with BERTEIG, and can be contacted by going to http://www.worldmindware.com/AgileTeamDevelopment
You want to be practicing Scrum! You’ve taken Scrum training, received your industry certification, and perhaps even experienced being a Scrum team member. In your heart you believe Scrum is the right tool and approach for you, and you believe your current organization and your customers could really benefit from Scrum practices.
However, for whatever reason your organization is either hesitant to consider Scrum or believes it’s a bad idea. Perhaps there was an experience with a poorly executed pilot. Perhaps your leadership see it as being too risky.
What do you do?
This article explores how you could subversively practice ScrumMaster-ing in your workplace without getting into trouble or breaking the rules. (Ssh…we won’t tell!)
Before you even begin strategizing, you need to ensure that what you do aligns with the Scrum values, namely:
Doing Scrum subversively will certainly take considerable courage, focus and commitment on your part. Be aware you will be challenged to respect the existing organizational culture and norms, and your organization may push back on your efforts.
You also need to acknowledge that the very act of being subversive means you are not being completely open or transparent that you are trying to practice Scrum.
Or you could tell your workmates, “I’ve had this terrific training in Scrum and could we try a few of the techniques to see how they work?” Then introduce something as simple as time-boxing or holding retrospectives with your colleagues.
You will also want to ensure what you do is harmonious with Scrum Theory and the pillars of empirical process, which are:
1. Transparency 2. Inspection 3. Adaptation
Normally, one could say there’s a direct conflict between being transparent and being subversive. Keeping this in mind, it is imperative you be absolutely transparent on the actions you are taking and what the specific goals, outcomes or learnings are that you hope to achieve.
However, given the circumstances you’ll likely choose to not use Scrum terminology to describe what you are doing. In other words, describe the practices and activities that you are implementing or recommending, express their benefits and what you hope to accomplish, but don’t explicitly call them by their Scrum name.
As for Inspection and Adaptation, those approaches should be perfectly aligned with your intent to try to help your company become a learning organization. That means you will need to park your ego at the door and accept the results. If your learning shows your subversive Scrum activities do not provide the benefit you’re aiming for, you will need to stop them regardless of whether you think they should work.
Let’s explore some activities and practices you may want to tactfully consider to help your organization benefit from Scrum (without actually “doing” Scrum).
1. Lead by Example
As someone that appreciates the values of Scrum, you should aim to educate others and provide them with a similar understanding. That means practicing these values in how you show up and in everything you do, even explicitly calling out certain actions when they are a prime example (whenever it is appropriate).
This does not mean preaching! Instead, it could be sharing your thoughts about something when contributing to a decision, or simply pointing out when and how something that aligns with the values contributes to a better team, a better experience, or a better solution.
Leading by example also means being human and honest when mistakes are made or when failures occur. This can be particularly risky in an organization that has not embraced Agility, or where failure is frowned upon. That is where you need courage, and a commitment on your part to hold improvement of the work above your own individual career needs.
2. Communicate More
Make a concerted, conscious effort to communicate with your team and partners more. For example, get up out of your seat and spend more time in informal face-to-face discussions rather than sending e-mails or chat messages.
Perhaps you can have short, informal meetings with just the team either daily or several times a week to see what’s been done, what needs to be done, and what challenges the team is facing. The key here is to keep it short, focus on what is needed to move work forward, and define actions to address issues. Then always follow up and make sure the actions are being pursued and that progress is shared with the team.
3. Be Open And Transparent
Although you may consciously choose to not use the proper terminology and language of Scrum, the key is to always be honest about what it is you are trying to do, why it’s important, and what the desired outcomes are.
To this end the goal should be to become an organization that “learns about learning”, constantly tries to improve, delivers value faster, and applies new knowledge in the best possible way. Scrum may be a fantastic catalyst for that, but there are many other approaches that will achieve similar results.
4. Use Better Meeting Practices
Another approach to consider is improve meeting experiences by time-boxing and defining a specific scope for each meeting. Setting a time limit and outcomes for a discussion helps create a sense of urgency, manage expectations and focus the conversation on the most important topics. The facilitator will need to enforce these constraints, otherwise you lose the effectiveness of the practice.
5. Have One or More Key Stakeholders Empowered to Make Product Decisions
This may be a considerable challenge in organizations where there is little appetite or understanding about Scrum practices, but do what you can given your authority and influence. If possible, try to have a single voice (key stakeholder) defined as the person with the final authority on the product or service that your team is delivering. Work with that individual to set them up for success by connecting them with the other stakeholders, perhaps facilitating discussions with them, and showing the key person(s) effective techniques for prioritizing the work that is being asked for.
6. Limit Efforts to What Matters Most
One practice that is important to apply, but often difficult to master, is focus. Limit work and discussions to the most important tasks and activities, and request that other discussions on lesser-important work be delayed. Always try to focus the conversation back to what is currently the most important work.
On occasion you may even want to point out times when plans were well-defined in advance but ultimately changed a lot when the actual work was in progress. This indicates the waste in planning too much up front and in constant task-switching. When done in conjunction with time-boxing this practice becomes a little easier.
On a macro scale, try to limit development to smaller chunks of end-to-end deliverables. In other words, deliver small things often all the way to completion as much as possible (e.g. to a staging environment). Then show the outcome and deliverable to stakeholders and customers, explaining that although the final product may not be done, this is to get them something fast and gather feedback.
7. Reflect on Learning
When possible, ensure that reviews of completed work happen frequently. Ensure the outcomes, functionality and value is shown and that learning (for the product as well as the methods) are part of the discussion.
Without becoming intrusive, seek stakeholder feedback frequently and informally. Be willing to demonstrate an ability to pivot plans based on that feedback.
As a team, hold informal retrospectives of how you worked together. If the term “retrospective” is contentious, consider calling them something else, such as a debriefing.
8. Visualize and Display Work
Have your own personal backlog and list of current activities visible at your desk. Use post-its to represent all work that you have on your plate, and ensure it is always up-to-date. Prioritize the work items you have coming up, and visually represent this as a rank-ordered list of things that you have to do.
It won’t take long for people around you to notice what you are doing and ask about it. Use this as a great opportunity to educate others on the values of transparency and focus.
9. Keep Your Team Size Appropriate
If you are on a particularly large team, see if it is possible to split that large team in to smaller groups. The benefit is more face-to-face time and interaction across the new team, an increased sense of belonging and commitment to the new team’s purpose, and it should also be easier (in theory anyway) to get decisions made and increase alignment.
The challenge will be finding a logical way to split the teams to mitigate dependencies of people, skills and products, and ensuring the new teams can still collaborate with one another. Geography might be a good way to split the team if you are distributed, but you would need to ensure all the skills to deliver the solution exist on all new teams.
10. Push for Automation
If you are in a development environment where tools, automation and engineering practices are not currently being used, and they could be of value to your organization, then start investigating whether it is possible. Tools and automation aren’t cheap or easy to implement, but they dramatically encourage you and your teams to collaborate better and they enable the adoption of Scrum practices such as fast delivery of value.
Be confident that your own creativity may help you unlock ways of practicing Scrum methodology without disrupting your organization’s practices.
You may or may not be able to implement all of the above actions but, as one Agile coach says, “it’s all about how YOU show up, how YOU are.” In the final analysis, your example, your enthusiasm, your courage will be the best you can offer.
“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:
Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
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.
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:
I dutifully watch Scrum Alliance’s webinars whenever they offer something I want to learn about, so I recently attended Michael Sahota’s “Top Ten Secrets of Agile Transformation.”
Sahota is a bit of an Agile guru, and well-respected in the community. He founded the Toronto Agile Community, and can be seen at Scrum Alliance gatherings everywhere. He also facilitates a Certified Agile Leadership course. You can learn more about Sahota by going to his website www.agilitrix.com.
The webinar he conducted was fascinating, because by the time he went from #1 to #10, I realized his “secrets” were very simple, and that one could start with #10 and work backwards to #1 and learn the same things.
By simple I mean his points were clearly articulated and comprehensive.
Before enunciating his secrets Sahota started with the idea that “Culture is the #1 Challenge with Agile.” He asked, “What are we (agilists) doing to create resistance to a change of culture in an organization?” Mindset, he averred, is more important than the practice of Agile – by which he referenced creating safe and trusting relationships, engaging with others, promoting continuous learning, innovation and so on. On a continuum line with “practices” on one end and “mindset/culture” on the other, he urged practitioners to find a balance between the two.
And now for the count-up:
Secret #1 – Clarify the purpose of bringing in an Agile coach by asking “why?” Usually the answers have to do with improving the quality of a product and encouraging more collaboration.
Secret #2 – Focus on organizational goals (and drop the word “Agile”). If the goals are clear, as those articulated above, one can drop the Agile initiative and try another. Agile is not the goal, but focussing on doing and being Agile can set up the wrong expectations. You may say, “Of course we will likely use Agile to help us achieve the organization’s goals,” but remember that Agile cannot be the goal!
Secret #3 – Focus on growth (and drop “transformation”). The idea of transformation is that it is a painful process. It also implies an end point: one is transformed. The idea of growth is more natural, and transformation is really about creating healthy change and growth. It is ongoing.
Secret #4 – Increase awareness of the global context. Global trends mean that an organization must be growing to survive. A lot of organizations do not know how to read their engagement surveys, or don’t even have them. People’s talents are wasted when engagement is low, which leads to massive financial waste. Millennials demand change – will not seek to work in an organization that’s regressive or stagnant. An agile enterprise is resilient and anti-fragile. How well is an organization set up to thrive in the future?
Secret #5 – Increase awareness of organizational context – what’s happening in an organization? However, resist telling leaders that their organization is broken. Start with humility and compassion, and then show leaders that there is a lack of engagement by their members by reading the survey. It’s not about blame – have the leaders acknowledge this and say what they want to do about it. What difficult conversations are needed here? The coach must stand in the truth of what’s happening, listen and understand. Be real.
Secret #6 – Clarify the focus of the initiative. Is more time spent on tactical initiatives (as in, how do we work?), in strategic initiatives (what do we want to achieve?), or in cultural concerns (who do we want to be?)? Discuss what percentage of time is needed to spend on culture in order to have a bright future.
Secret #7 – Build a shared understanding of what culture is. Culture has to do with both consciousness (or energetic property) and structures. Consciousness includes identity, values, beliefs, and the unwritten rules and norms in an organization. It includes values such as safety, trust, people being valued… Structure (practices) and consciousness (culture) co-exist together and are inter-dependent. Refer to the Agile Manifesto: people over process. – focus on structures without consciousness cannot succeed.
Secret #8 – Clarify the leaders’ role in growing. The consciousness of the leadership is most important. New organizational behavior requires new leadership behavior. Growth requires leaders go first! How do we invite them to go first?
Secret #9 – Honour the leaders’ freedom to choose. Do they wish to work on something tactical? Cultural? A coach must let go of what he or she wants. We cannot coerce people into believing what we believe.
Secret #10 – Growth can happen anywhere.You, as an individual, are the limit for growth.
Sahota suggests creating a culture-bubble in which consciousness and safety can be grown. In this last point he quotes Gandhi: “Be the change that you want to see in the world.”
I am aware that in the 45 minutes of the webinar, Sahota went through each point relatively quickly. Each one in itself provides room for reflection. For me, the fact that the tenth “secret” puts the onus on each individual to grow is telling; if we change, we can help those around us in their transformation. But that requires extra-consciousness, I think, and humility. Overall, Sahota points to values and culture within and without as the key.
“Sometimes we get so caught up in what should be that we miss the beauty of what is.” – Doc Norton
At the 8th Annual Agile Conference, held in Toronto, Ontario last week, the keynote speaker Doc Norton presented some insightful ideas on Host Leadership, about the roles people take when initiating, launching and facilitating new ideas. The basic premise of having a Host Leader mindset is to be fluid with the needs of the environment. While there is a time and place for authoritative decision-making, otherwise called gate-keeping in Host Leadership lingo, there is also a need for a humble approach to supporting an idea from conception to fruition without clinging to hard-and-fast expectations about what must happen.
In his example of applying these principles, he shared how his family decided to host a Euchre game to create an opportunity to meet new neighbours. When something different than expected emerged, he experienced the value detaching from “what he wanted it to be” and accepting “what was becoming.”
In brief, here are the 6 key aspects of Host Leadership.
Initiator – The person that provides the initial spark. A new idea.
Inviter – Extends the invitation to people who may be interested in the idea. Who to invite and who not to invite.
Space Creator – Those who create the physical and emotional space for those in attendance to feel safe, to learn, and to engage in the opportunity.
Gate Keeper – Defines and protects the space which is created. Lets people in and out as necessary or appropriate. People who enforce the rules, doing interviews and hiring. Note: there is a right balance for this where there is not too much gate-keeping but just enough to create the right boundaries.
Connector – Brings people together. They are conduits for information. They are typically the ones who know how things get done.
Co-participator – Team leads participating in a retrospective as equals.
Sometimes the Host Leader sets and reinforces rules, but sometimes they serve others. This depends on the moment and context.
Doc Norton laughed at his own story when he revealed that even though he and his wife put lengthy effort into creating “Euchre Night” he discovered that in the basement a large group of guests started playing poker. Rather than becoming disgruntled about the change, he adapted and became a co-participator. As a result of letting what was becoming just be, the neighbours found themselves carrying out Poker nights monthly for a decade.
Host Leadership is about creating space for great things to emerge and surrendering the inclination to control the outcome.
These six items are aspects of roles of everyone on a team and shouldn’t be thought of as one person per role per team. Instead, when people on a team ebb and flow around these roles the thought-processes and discoveries can be shared with the team, and the growth on the team supports the initiatives for team members.
What were his concluding words of wisdom to the audience?
He said, “Consider your leadership role at work. Regardless of your title, think about what you are initiating. How do you extend invitations? What space are you creating and maintaining? When are you gate-keeping? How are you connecting with others? How are you joining what is emerging even if it is different than what you expected?”
The take away from this inspiring opening address was the optimistic message that what is becoming may be better than anything anyone could have hoped for.
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.
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.
Leading an organization to Real Agility requires that you communicate the vision for change throughout your organization. This video introduces the four key concepts of communicating this vision for change as you and your executive team lead your organization to Real Agility.
The video presents four core concepts:
Continuous communication at every opportunity: every meeting, every phone call, every email, every presentation!
Simplicity of the message: short, jargon-free, concrete.
An emotional component that encourages a change in behaviour.
And urgency! (A window of opportunity, a competitive threat or an internal problem that needs to be addressed now.)
Leading to Real Agility References
Here are some additional references about how leaders can help their organizations move towards Real Agility by communicating the vision for change:
Mishkin Berteig presents the concepts in this video series. Mishkin has worked with leaders for over fifteen years to help them create better businesses. Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer. Mishkin is co-founder of BERTEIG. The Real Agility program includes assessment, and support for delivery teams, managers and leaders.
She agreed to pick up a care package from me weekly. And that’s how this social action initiative was born.
Once I knew I’d be doing this weekly, several logistics had to be sorted out. Where was the food coming from? Where would I store the food between pick-ups? When would it be picked up?
Interestingly, I don’t have enough food in my own cupboards to share with someone weekly. Fortunately, I know many others who are like-minded and highly value supporting and helping others so I began to reach out. Within days I had more than seven bags of food to share and it occurred to me that this would be my goal – 7 bags for 7 days. That should get her through the week.
It didn’t take too long for me to see that if I considered myself as the Product Owner of this product – a weekly food package – that there might be valuable Agile concepts and practices which could easily help support the sustainability of this initiative.
“Is this a Project or a Product?”
Immediately, an Agile Coach inspired me to think of this not as a project, but as a product. The main difference, he reminded me, is that a project has a start and an end. A product doesn’t have an end date. It can always improve.
At the beginning, I thought of this as a “project.” You know? A bunch of us getting together with the vision of sharing food weekly. It was our “Food Sharing Project.”
Before long, I realized that was an old way of thinking about work. When I thought about the food package as a product a lot changed. It became easier to see what was needed for this product to be useful to the recipient. The quality of this product became clear.
I also watched this video from Mishkin Berteig which encouraged me to think about the ways in which this package could be run with Scrum. (So far, I am the Product Owner. Now I just need a ScrumMaster and Scrum Team. You never know, maybe this will evolve some day!)
Then I read this article by Mike Caspar which got me thinking about acceptance criteria and the importance of consultation, reflection, learning and planning.
The key learning for me today is that when I think about this service of delivering a weekly care package as a product I see it’s likely it can continue indefinitely, always improving. That really excites me.
It is not a project, but a product and is being organized and delivered using Agile methods.
This is one way that Agile is being used outside of IT with great success.
This video, newly released on BERTEIG’s YouTube Channel, reminds leaders of their responsibility to communicate the vision to their organization. Check out the 2-minute video for valuable insight into the process.
What I like the most about Agile-thinking is the principle of taking action with very little planning. This philosophy of learn-as-you-go creates space and time for the team to experiment with ideas to create a successful product.
For the past year, I have participated in an agile experiment of sorts. Basically, the goal was to write a weekly newsletter. But more specifically, the intention was to create meaningful content to readers of the newsletter which would empower them to continue to make positive change in their organizations by applying Agile methods.
Six weeks after starting the newsletter, I attended my first Certified ScrumMaster (CSM) training in Toronto, Ontario. At first, I thought I could manage the newsletter content and delivery using Scrum. I quickly realized I couldn’t. Even if I viewed myself as a ScrumMaster, I wasn’t working on a Scrum team. There was no Product Owner. It couldn’t be run using Scrum.
However, I realized something essential that I could glean from Scrum and that is the idea of Sprints. I realized right away that if I viewed the creation and delivery of the newsletter in one-week Sprints I likely could be successful. And indeed, this application of a Scrum method was extremely useful.
Thinking about delivering a newsletter in one-week Sprints helped me to think about the smallest amount of content which could be easily and predictably delivered weekly. As my capacity, and the capacity of the team improved, so could the level of complexity also increase.
As the level of complexity increased, the newsletter itself improved in quality.
I would like to write more about how a newsletter can be created and distributed using Sprints and other Agile methods because doing it this way helped me to stay adaptive & flexible as the newsletter was refined.
5 keys for using Sprints to create & distribute a newsletter
Understand “Done Done!” – Before CSM training, the newsletter was “done” when I pressed ‘send’ on my computer. When I better understood the meaning of “Done Done” in a Sprint I changed my thinking and behaviour. When I sent the first draft to be proof-read, this was “Done” and when it was returned to me edited and when I did final revision then it was ready for scheduling. When I pressed “Schedule” then the newsletter was “Done Done.” I would plan to schedule the newsletter three days before it was expected to be released. That gave me three days of ‘buffer’ to accommodate last-minute changes, if necessary. I was learning to become more Agile.
Learn to Accommodate Last-Minute Changes – If last minutes changes cannot be easily accommodated, then the product delivery is likely not Agile. When I started creating and distributing a weekly product, with the expectation that things could change at any time then I learned to establish a “bare-minimum” which could be produced even if changes occurred. This gave me the ability to be flexible and adaptive and much more Agile.
Be Agile; Don’t Do Agile – When I went to CSM training, I thought I would learn how to do Agile things on my team. When I completed the training and started applying Sprints to the weekly distribution of a newsletter, then I realized I must “Be” Agile in my approach, in my communications, and in my creation of the product. I learned that Agile is really a state of mind and not a “thing” at all. Agile is about continuous action, reflection and planning with an open-mind and a readiness to always learn and grow and change.
Action, Reflection, Planning – Before using one week Sprints, I didn’t give myself enough time to reflect and plan the next Sprint. I had a backlog with enough items to keep me busy for 6 months. My work-in-progress was a nightmare and unmanageable. I had four weeks worth of drafts saved and often got confused between what content was going out when. Establishing a regular weekly cadence helped me take control of this “mess” by just taking small action steps, reflecting on them weekly, and using the learning to plan the next steps. This revolutionized my work.
Prepare For Growth – When a product is delivered successfully with Sprints, it keeps getting better and better. This leads to goals being met and growth happening on the team. In this case, it lead to increasing numbers of subscribers and the establishment of a collaborative team approach to creating and distributing the newsletter. Without Sprints, without an Agile mindset, I’m absolutely certain the goals would not have been achieved and growth wouldn’t have occurred. But with Sprints, things just keep getting better and better every week. I love it!