We see it over and over - let’s learn how to work together and fix broken or outdated processes but we must still deliver a three-month feature in two months while we are doing it. The patient is sick but would still like to go run a 100 meter dash tomorrow.

Breaking bad habits and establishing new ones will take time but we still have a business to run. I understand the dilemma – we must remain viable or we cease to exist.

So, how do you begin to fix what is broken while you still need to deliver? How do you care for those hurting or disengaged in your workforce while still asking them to produce? Here are a couple of thoughts:

Have an underlying cultural vision. If what we have today is not working well, what should the future look like? What will people say about their experience at your company when they leave or retire? What will be the legacy on the health and well-being of your people? Here is a great interview about knowing what kind of company culture you are looking for and how to start building it. When you know what you want to become, everyday decisions and behaviours start to align.

Build and support a team of enthusiasts. Find the passionate ones.  They are usually easy to find and once you do, bring them together often to encourage and support them in finding ways to live into the cultural vision.

Impact one person at a time. This made a world of difference for me. When the problems are so deep and the amount of dysfunction feels so daunting it often feels like there is no hope. When I feel this way I look for one person who is skeptical or find someone who at one point was passionate about their work but has been beat down by bureaucracy and distrust over the years. Connect with that one person and begin to coach and encourage them. Then connect with another…

Be a little stealthy. Remember the movie “The Karate Kid?” Throughout the movie, Daniel-son didn’t realize he was learning karate when Mr. Miyagi was having him wash cars and paint the fence. But indeed he was learning quite a bit… 

Small moves done everyday will lead to bigger changes. Mr. Miyagi didn’t need to use the word “karate” – you don’t need to use the word “agile.” Just begin modeling and teaching people new ways of working together.

Have a plan. It is possible to work on a beating heart but you must have an approach and techniques to provide a safe environment and the right results. We have often used a three-phased approach for transformational journeys and you can read more about it here.

The post Working on a Beating Heart appeared first on Illustrated Agile.

Many of these companies are attempting to become agile, nimbler, leaner or more customer-responsive with varying degrees of success. The struggle, I believe, for these organizations to truly change occurs when leaders are not ready for what becoming Agile will bring – the amplification of both the good and bad behaviors from their current situation.

If you have hired well, the amplification will result in a near immediate boost in a sense of empowerment and productivity for your people. Bright, hard working people thrive on Agile teams. The reaction to this amplification must be a letting go of control by leaders and of overwhelming encouragement from your leaders.

If your organization has not hired well, the amplification will put a spotlight on those who have not been performing or are not good teammates. The reaction must be a hard look at current hiring practices and your approach to performance management (if you can really “manage” performance at all). Fresh thinking from leaders will be needed in this space.

If your technology has been allowed to grow in complexity and fragility, the amplification will be in frustration. Agile teams will begin to increase the throughput of production-ready code but will not be able to realize customer value quickly enough. The reaction must be simplification and a shift to being “anti-fragile.”

If there is a history of having a fractured or siloed organization, the divide between groups will be more apparent than ever. The reaction from leadership must be to foster and facilitate reconciliation and connection. Don’t expect people “to go figure it out.” Rather, become a model for the behaviour your people need. Bring people together. Solve things together.

If there is a lack of vision, direction, or prioritization, the amplification will reveal a craving for it. The reaction must be to discover what the organization should be passionate about and provide the motivation to achieve it. Agile teams respond amazingly well to a well-crafted and well-communicated vision.

Leaders, be ready for and react to what will be amplified during your transformation to Agile. Meaningful, lasting change and more importantly, your people, will depend on it.

The post Agile, The Amplifier appeared first on Illustrated Agile.

When we begin introducing agile into organizations, the impact is often strongly felt by the testing community. Testers are an easy target when bugs are released into production and are often the focus of blame. Because of this, testing groups have built heavy processes and sign-offs to protect themselves from what they know will be coming later. Trust will need to be restored before testers will fully engage and freely interact with a team.

In dysfunctional situations, developers and testers will often come into a team thinking of each other in one of four ways:

The Outsider. You don’t know enough about what I do so I’ll keep you in the dark or ignore you for as long as possible until you just go away.

The Obstacle. You’re on the team but I don’t like it. I’ll do just enough to keep you off my back and nothing more.

The Speed Bump. I know you’re there for a reason and I should slow down a little for you but why bother.

The Enemy. “Your code stinks.” “Your testing stinks.” Repeat.

Obviously, none of these attitudes will go very far on an Agile team. We must find a place of mutual respect for each other, value each other, and become amazing agile teammates.

Start small but start with something. If the relationship between developers and testers has a history of being toxic in your organization it will not go away on its own and the effects of the dysfunction will only be amplified on an Agile team. Quality must be a team event.

Empower your Scrum Master or Agile Coaches to use subtle changes to build (or rebuild) a foundation for the testers and developers to form their relationship on. Here are a few activities to consider:

Learn about customers together. Schedule a field trip with the entire team to watch people use your product, app, or web site. Seeing the impact our work has on people (both positively and negatively) brings clarity to what is really important.

Build stories and acceptance testing together. Rallying around the user will further shift the team to a position of focus on who will receive value from what we are building. If they aren’t already, have developers and testers author acceptance criteria together.

Mature your definition of “done.” If you haven’t looked at your definition of done lately perhaps it needs some attention. As the Scrum Guide states, “As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.”

Create unit tests together. This may be a challenge but worth suggesting. Try having a developer and tester “pair” while writing a suite of unit tests. The quality perspective from the tester and the extra set of eyes could be beneficial and begin breaking the ice.

Emphasize conversations around quality and “done” over tools and process. Don’t track bugs on currently in progress stories as a defect. I have seen teams want to do this but resist the urge…the story just isn’t finished yet. If conversations aren’t enough just write a task for the bug and add it to the information radiator.

The post When Developers and Testers Collide appeared first on Illustrated Agile.

An organization striving for agility cannot be truly agile with a fearful workforce. Period.

As this interview in the New Times states, “…the brain categorizes everything into one of two categories: threat or reward. We’re driven unconsciously to stay away from threat. We’re driven unconsciously to go toward reward.” The entire article is worth reading if you get the chance.

When people feel threatened, they will turn from you. They will become defensive at best and at worst, they will disconnect fully.

Now, this does not mean we accept poor performance, ignore bad team members, or avoid opportunities to teach or mentor. In fact, it should be the opposite. If we use the right words we will inspire people to expand their own expectations of themselves and dream big dreams. They will become self-motivated to live up to their own expectations – and not yours.

When the best leader’s work is done the people say, ‘We did it ourselves!’ – Lao-Tsu

Your entire view of leadership will change when you replace your own expectations for people with a focus on making personal connection and instilling confidence. It did for me.

Begin making personal connection with your people today by considering a few actions:

Become self-aware. The first step is recognizing your mindset must shift. You, dear leader, are the one who must change – no one else.

Love. Do we dare say this word within the walls of business. My friend Si Alhir has written a short but engaging post based on Robert Sternberg’s Triangular Theory of Love. You may say “Some people are impossible to love!” If you remove your own expectations, are they really?

Connect. Know everything to know about the people who report to you. Birthdays, anniversaries, spouse’s name, kid’s name, dog’s name, everything. Condemnation becomes much harder when you recognize others are human just like you and dealing with the same stuff life is throwing at you.

Heal. It is a rare occurrence when a leader apologizes to a direct report but when it does something magical happens. This is hard to do but for the restoration of trust and connection to develop, genuine forgiveness may be necessary.

The post Personal Connection vs. Bringing Condemnation appeared first on Illustrated Agile.

With the last post of the series, I’ll share a few thoughts on how we can begin to build a free-flowing partnership between leadership layers and product teams.

The communication conduit often clogs at mid-level leaders. The strategic vision does not reach the teams and if it does, the vision has been filtered to a point where it no longer resonates or inspires. Insight into user needs and potential product features found during discovery from the product teams only reaches so far into the visioning exercise or doesn’t happen at all.

To function with business agility we will need to see an unwavering level of responsiveness to changing business and market conditions. It will also require a resilient level of trust and respect to attempt new things and build on ideas from every corner of the company.

To ultimately make the level of nimbleness and adaptability necessary to be competitive I believe, as others do, organizations of the future will need to be less hierarchical than they are today. But until that day arrives, here are a few starting points to consider:

Focus outward. Redirecting our energy towards our customers will require a bit of selflessness. It will mean being generous with each other, primarily through learning how to really listen to one another. Instead of being the hoarder of information, our first response when new data, theories, and ideas arrive should be “who should know this?” Become a radiator of information to all.

Learn how to resolve conflict. As we all know, there will be different opinions and beliefs on what features will best meet our customers needs. All one needs to know about how innovative an organization is can be gauged by how they work through these conflicts. From the Denma Translation of the Art of War, “This is not simply about bringing the other person over to your side but bringing him or her to something larger than either side.” This is where real innovation and collaboration lives.

Temper the vision with reality. As Thomas Edison said, “Vision without execution is hallucination.” If the vision calls for revolutionary innovation, more investment may be required or serious prioritization must occur during planning. Bring organizational feasibility into the vision by co-creating with mid-level leaders and product owners.

The post Finding Organizational Flow (Part 9 of the Agile Leadership Engagement Series) appeared first on Illustrated Agile.

The output of learning and discovering our users is captured in a product vision. The product vision should simply be identifying who they are, what needs they have, and what features should be created to satisfy those needs. The features generated with the product vision will feed the product backlog created in Part 7 of this series.

Product discovery should not be done in a vacuum and ideally, not be done in isolation by only the product owner.

An earlier post of mine discussed this concept of performing user discovery as a partnership between the roles of product owner, architect, and user experience designer. Each role brings a unique perspective to the vast array of possible features and provides a balance and filter for the product owner. If possible, I would leverage this approach.

Creating a product vision is not easy and will take a considerable amount of time and energy and should be constantly evolving. I would not consider myself an expert in product visioning but there are awesome resources available from real thought-leaders in this space such as Mind the Product and Marty Cagan to help.

I have however, interacted with many product owners and coached product teams through product discovery activities. From what I have seen and experienced, here are couple simple tips to remember:

Become them. This is nothing new to most of you but the use of personas and customer immersion techniques are useful in discovery. Depending on your product, you may also need to get out of the office to hear what your users are saying. Whatever techniques you use, it’s crucial to have real customers speak to you and for you to listen.

Let them try things out. There are times in discovery when you may develop theories about how a product or feature would meet needs the user or customer. In this case, use small experiments to confirm your theories. Obtaining answers in discovery is cheaper than in delivery.

Stay in discovery. As much as realistically possible, product owners should spend most of their time in discovery. There is a temptation for product owners to get heavily involved with the delivery cycles of the team. While we love to see product owners being interactive with their team, solving day-to-day impediments someone else should be solving detracts from valuable time with our customers. Scrum Masters play a key role here.

Inform leaders. When you learn new things about the customer, let your leaders know. Share your theories on user behavior with them as your discovery should continuously feed into the evolution of the overall organizational vision. We’ll cover this in our last post in the series called Building Partnership.

Note: I know there is debate to whether one should use “user” or “customer” when referring to the people interacting with our products. I fall under this camp.

The post Learning About Our Customers (Part 8 of the Agile Engagement Leadership Series) appeared first on Illustrated Agile.

With the organizational vision in place and agile teams established, product owners will begin to determine the features to be added to their product. The features are usually captured as part of the product vision, which we’ll cover in the next post.

These features are laid out over time in a product roadmap and expresses, in broad strokes, planned future releases. The challenge typically comes when synchronizing individual roadmaps and releases with others in a portfolio of products. Leadership involvement in the product roadmap creation should be through continuing support at the senior level and planning coordination across the organization by mid-level leaders.

To start preparing the way for effective delivery of the vision and ease some of the complexities of cross-team planning, here are a couple of thoughts to consider:

Establish product syncs. Setup a frequent cadence for product owners to share their product vision and roadmaps with each other. This is especially useful for product teams with shared code, components, or technical infrastructure. This opens up the possibility of product owners “trading” features with another product owner who will be delivering a similar feature or touching the same code.

Build architecture roadmaps. Another useful work product would be to create an architecture roadmap for each product. Similar in format to the product roadmap, the architecture roadmap would layout key architecture decisions, implementations, or upgrades affecting product delivery.

The architecture roadmap would be created by the architect or technical lead on the product team and would always be at least three to six months ahead of the. The architecture roadmap would also pull from enterprise architecture to align all products and systems with the enterprise technology vision. In the same way as with product syncs, technical leads from each team would sync with each other to coordinate their roadmaps.

Find cross-team connection and collaboration points. Johanna Rothman has written extensively on this subject and I would recommend reading her blog posts. Johanna recommends Communities of Practice for cross-team coordination and I agree. If you are interested in getting Communities of Practices, here is a post with an approach to get them started. If your Scrum teams are integrating with traditional waterfall projects, include them in your network of connections and use those dependencies to make your roadmap decisions.

The post Preparing to Deliver (Part 7 of the Agile Leadership Engagement Series) appeared first on Illustrated Agile.

Depending on the size of your organization, the planning (or portfolio management) for your product teams and subsequent product roadmap creation may become quite complex as aligning priorities and dependencies is often challenging. Senior leaders can help.

Here are a few things senior leaders can use to make this process easier and support their mid-level leaders and agile teams while they are planning and coordinating:

Establish clear boundaries. Communicate any organizational constraints mid-level leaders and teams should be aware of prior to planning and roadmap creation. This would primarily be budgetary or technical (from a CIO or similar) but there may be others depending on your situation.

Provide clarity of vision. Questions may emerge from your leaders or teams on aspects of the vision. Be available to assist them and be able to paint a vivid picture for where the organization or product suite is heading.

Assist with prioritization. Many opportunities, features, technical advancements, and areas for innovation and improvement will be competing for the attention of mid-level leaders and product owners as they build product teams and product backlogs are established. Be available to assist in prioritization discussions if requested.

Expect hard decisions. With prioritization comes decisions. Often times these decisions will be hard as it is not easy to say no. The temptation may be to delay making some of these decisions as it’s not popular to tell people their project or request will not be happening when they would like. Constraints will require choices so expect your leaders to make them.

We have now covered the three areas of focus for senior leadership in our Agile Leadership Engagement Model: creating the vision, supporting planning activities, and encouraging the organization.

Obviously, there will always be more responsibilities than those represented in this model but by focusing on these specific areas during an Agile transformation, senior leadership will understand where they are most needed by agile teams, when their support is required, and when their effort should be concentrated on relationship building and encouragement.

The post Supporting Team Planning (Part 6 of the Agile Leadership Engagement Series) appeared first on Illustrated Agile.

Transformational leaders have shifted from day-to-day command and control tactics to a focus on aspirational and directional vision. They set up networks and connect the organization in ways never thought possible. Most importantly, they are building people up and are concerned about the overall health of the people in the company.

To be the transformational senior leader your agile organization needs every day, here are a few tips to try:

Be visible. Tom Peters calls this MBWA – Manage by Wandering Around. As Mr. Peters states “this is a metaphor for being in touch, a metaphor for not losing touch with your employees, your vendors, your customers.” Use your wandering time to continue to communicate and promote the vision but primarily to build relationships.

But stay out of the way. While wandering, don’t use this time to get to involved with the details of the products, as tempting as it will be. Use this time to get a pulse of the organization. This is your chance to show trust and begin to learn about people and how they do their job everyday. Ask powerful questions and build empathy for what the people of your company do to bring the vision to reality.

Temper your reaction to “failure.” The heartbeat of a team will be influenced by the reaction of its leaders, every time. Over-reaction will cause the team to lose faith and courage. This may be a good opportunity to coach and mentor a product owner but you must be able to trust them completely. Also, your mid-level leaders are watching so provide a good example for them.

Monitor what needs to be monitored. And nothing more. Focus on key performance indicators for the features the teams are developing and other meaningful organizational metrics. It’s easy to bog a team down with status reports and data requests but try to keep this to a minimum.

Make everyone feel bigger and confident. Be a genuine, full-force encourager. When you encourage someone you give them heart, you give them strength, your give them energy, you give them courage. The origin of the word encourage is actually “to make or put in courage.” How much courage have you put in to someone today?

Imagine a fully encouraged and engaged workforce, aligned to a shared vision, working collaboratively and without fear. I believe it is possible but it will start with small changes and daily decisions.

The post Encouraging the Organization (Part 5 of the Agile Leadership Engagement Series) appeared first on Illustrated Agile.

As the product teams are building momentum through sprint delivery cycles the most beneficial activity for mid-level leaders would be to remove big impediments.

Many big impediments are the result of incomplete or poor planning during the Building Out the Vision activities mentioned in Part 2 of this series. This would include incorrect team composition, size and dedication, enterprise-level technical feasibility has not been validated, or lack of prioritization.

As a mid-level manager or leader in an agile organization, here are just a few of many possible ways to remove the big impediments keeping your team from amazing things:

Handle bad team members. As a leader and manager, the most important impediment you can remove will be relieving the team from a toxic team member. We hope this rarely happens but it does. We give everyone a chance to be a contributor and partner with the team but sometimes the connection just isn’t there. It takes just one person to derail a team so act quickly when necessary.

Destroy silos. Some of the hardest and most damaging impediments to tear down are those relating to departmental silos. Be a connector within your organization by removing process and sign-offs between groups. Think about ways your teams can co-create with others departments in your organization instead of passing around paper and email.

Solve large-scale technical issues. Like many organizations, including the ones I have been associated with, you probably have lingering technical skeletons in your closet. Your product teams and support groups have established workarounds and kept things running with duct tape and baling wire. Leveraging continuous integration and delivery will be challenging without resolving some of these technical constraints.

Shield the team. This is a tricky one to handle but there may be leaders (especially the senior type) who would like to continue to interact with product development on a daily basis. This puts the product owner in a tough situation as the product roadmap becomes littered with features they may not truly believe in. The product backlog begins to align with leader needs and does not align with customer needs. Become a filter for the requests and ideas of leadership before they affect the team. Just how the interaction between leadership and product team could happen will be covered in the last post of this series.

The post Removing Big Impediments (Part 4 of the Agile Leadership Engagement Series) appeared first on Illustrated Agile.