How to Manage Remote Stakeholders During a Sprint Review

Herwig said,

Some stakeholders of our project are often abroad, but want to join interactively the sprint review. I’m of course in favor but I’m looking for appropriate tools to facilitate this.

Hi Herwig,

Sounds like you have a common constraint. There is more than one way to solve for this kind of problem. No matter what the method, the goal is the same: To help the remote stakeholders understand what was done and to ensure their voice is heard during the interactive session. Here are some suggestions.

Create a pre-staged video of the demo and send it to them before the interactive session

One of the challenges of group sprint reviews with a conference call is that the conversation and q/a becomes very ad-hoc. The people on the conference lines often can’t hear the side conversations and don’t get the full benefit of the in-person review. Sending them a pre-staged video of what will be demo’d will help them to more easily be able to follow along with the real sprint review. The questions they will ask will be based on them getting a first-hand view of the new features without the distraction of 10 other people in the room or a clunky video signal.

Have the demo-application deployed in a place where the stakeholders can explore the new functionality themselves

If your teams are mature enough to have designed-built-tested-documented-integrated code, you should be able to make the application available in a non-production environment so the remote stakeholders can click around for themselves and test-drive the new features. This will also help them to be able to follow along with the sprint review more easily.

Create a high level “outline” of the features to be reviewed

Distribute this outline before the sprint review. In my experience, not every stakeholder is interested in every feature. Having a “program guide” of sorts will not only help them manage their time and engagement but also help the team sequence the sprint review with a disciplined approach.

While we would love to have our stakeholders in the same room for the sprint review, in 2015 its often not possible. Hopefully some of these tips will help you overcome the distance constraint.

I hope this information was helpful for you. Click here to download more information on managing remote stakeholders.

Until Nex Time,

Stay Agile, My Friends

 

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Use Your Agile Skills to Land a Better Job

shutterstock_248174011

“I’m the best Scrum Master in this company, and I get no appreciation.  I haven’t gotten a raise in 3 years!!”
“So why are you still around?”
“Because I care and I think I can make a difference!”
“Ok, but what is it that you really want?  Your current company has shown they don’t really value you”
“I want to go to a place where I’m appreciated and I can make a difference”
“Ok, I think it’s time for you to find another job…”

shutterstock_220086301

Why we don’t have the job we want

Because we have notions of career progression straight from the 60’s:  “Work hard, do everything you’re told, and you will be recognized for your contributions.”  Let me ask you something, how many of you have done just that… worked hard, did everything you were asked (and more), and sat frustrated while some bozo who skates by on other people’s work gets all the promotions?  How many times have you seen someone who sucked at their job but was great at politics continually get recognized as a “game changer” in your department?  Why are you working hard and doing everything you’re asked while the sociopaths kiss up and get all the glory?  Because the bozos know something you don’t (yet) know:  Visibility is the key to raising your profile and having your choice of great jobs.  All things being equal, hiring managers will hire the person with the most visibility.  Its a branding thing.

shutterstock_236186596

Start a blog

When Agile professionals ask me about how to land a better position.  The first thing I ask them is “Do you have a blog?”  If they say yes, I ask them, “When is the last time you have written anything?”  I’m usually met with a sheepish grin.  The difference between those who have high visibility and a platform to continually grow that visibility and those who do not is… consistent demonstration of expertise.  How do you consistently demonstrate expertise?  Consistently write.  So sorry, your blog that has the most recent post as August 2012 does not count, otherwise, you’re “Just another wordpress blog”

shutterstock_121861366

Engage with your local agile community

At the San Diego Agile monthly meetings, someone is always either looking for a job or looking to hire.  Those who are looking to hire are looking for ways to find the most attractive candidate.  The best candidates are the ones who are involved.  They are constantly learning from the best in the industry, and consistently refining their skillsets to match those that are the most sought after in the market.  The local Agile community is a great place to let people know you’re looking (then send them over to your blog).

shutterstock_243396313

Speak

I hear the excuses already, “I’m not an expert… I’m just a .. <insert job title here>.”  There is one thing you are an expert in is your journey.  That is to say even an experience report of your personal Agile journey or your company’s Agile journey.  Some of the best speakers don’t start as experts.  They start as someone willing to share their experiences.  Pro tip:  Start with speaking at your local Agile user group meeting.  They tend to be more forgiving as an audience and you can work out the kinks in your talk.  Speak at other regional Agile user group meetings too.  It helps raise your profile in a broader area, and the name recognition helps when looking for a new position.

Give me the to Growing My Influence

Until Next Time,
Stay Agile, My Friends

Interested in building your profile and influence and getting more speaking engagements?  Download my “Guide to Growing Influence

 

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Your Company Should Create Its Own Agile Process

shutterstock_191157881

I was on a phone conversation with a client, and he was relaying a common refrain, “We’re doing everything by the book.  We’re seeing some good results but good golly its painful!”  This client in particular was 3 years into their agile journey, with a well enough established process to understand where the hard edges were for their company, their product, and their culture.

While companies new to agile should follow “by the book” frameworks as closely as possible, companies that are some years into the journey MUST create their own agile process in order to continue to see improvement.

shutterstock_105129812

Best practices are only the first step

Most companies seek the advice of experts such as Agile coaches, consultants, and trainers in order to find out what everyone else is doing.  The stuff that works is called a best practice, and consultants are more than welcome to give you those as a blueprint.  What you have to keep in mind is that a best practice is something that has worked well for someone else, and it may or may not work well for you.  To take your adoption to the next level, you have to stop consuming best practices and start producing best practices.  Relentlessly experiment with practices and results.  Based on results, make tweaks to the process to make it work better for your company, creating a new “best practice” for others in your industry.

shutterstock_225626866

Your business is unique, your process should be too

There is much value in understanding and incorporating standardized frameworks into how your company operates.  There is more value in deeply p understanding those frameworks and why they work well, then using that to create custom frameworks built for your business.  This creates a competitive advantage for your company because what you create wont be found in any book.  Look to examples from companies like SalesForce and Spotify for examples of how they took basic Agile frameworks, augmented them, and used it to become leaders in their respective industries.

shutterstock_190923122

Off the shelf Agile frameworks are purposefully incomplete

When you envision everything that needs to happen for your company to take an idea from concept to cash, then compare that to what the off the shelf frameworks have to offer, you will see gaps.  This is because most Agile frameworks are built to be “purposefully incomplete” in that they couldn’t possibly account for everything that needs to happen for every business type.  The frameworks that attempt to be more comprehensive can come across as bloated and prescriptive.  Start with a lightweight framework such as Scrum, then progressively bolster gaps with customized add ons that fit into the core process.

shutterstock_243240229

Beware of pitfalls

While there are upsides to creating your own Agile process, there are also some downsides.

  • Companies try to rush and create a process before they understand the problem to be solved.
  • The often attempt to modify a core framework they don’t yet understand.
  • They attempt to design a perfect process up front.
To avoid some of the same mistakes other companies make when creating an agile process, get my FREE “Custom Agile Processes, Avoiding Mistakes” email mini course.

Tirrell Payton is the principal at Payton Consulting, a San Diego-based boutique consulting firm that helps companies improve their technology capability to match their business ambitions.

Until Next Time,

Stay Agile,  My Friends

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Agile Software Development Is Not Enough and Agile Product Management is the Answer

shutterstock_181081433

“Hi, I’m Tirrell.  Thanks a lot for taking the time to chat with me about what you need and how I might be able to help.  So tell me, what is the problem you’re trying to solve?””We want to be more agile”
“Ok, but what does that mean?”
“We want to release software faster and still keep high quality.  We want to improve the productivity of our developers”
“Thanks.  For a second, let’s take a step back from the developers, and talk about the organization… what business goals with ‘going agile’ help you achieve?”
“I never thought of that….”

shutterstock_189271475

Software development does not exist in a vacuum

In most organizations, software development is a supporting function for the rest of the business.  The reason the software teams get so much attention when it comes to “measuring productivity” or “becoming more agile” is because software is typically looked at as a cost center.  This means when executive leadership are trying to figure out how to do “more with less”, they look at the areas where the largest amount of money is being spent.  Since engineers and technologists are not cheap, IT and software development is the first place they look to try to improve cost structure or gain efficiencies.

However, the effectiveness, quality, and productivity of a team is more a result of upstream processes and the overall environment than process magic.  In other words, there is no process, agile or otherwise, that will fix problems with your development teams that originate elsewhere in the organization.  While there are actions we can take to improve the teams’ performance, the outcomes will be localized to the extent our problem solving is localized.  System-wide improvements require system-wide changes.

shutterstock_153256433

The most neglected piece of the puzzle is effective product management skills

Technologists are an interesting sort; we are fiercely independent, yet we take pride in our work and genuinely want to help solve business problems.  However, most of the issues that manifest in the development teams manifest upstream of the teams.  The product managers are directly upstream of the development teams, so  this places product management squarely in my sights when I am diagnosing development problems in an organization.

shutterstock_204987514

Product managers typically suffer from common issues

  • Lack of training.  Most product managers that I have interacted with have had little to no training as product managers.  They may have come from marketing or customer support or occasionally engineering.  While they may be strong in some areas (product design, spec writing, etc), the core skills I would expect from a strong product manager (customer development, business case development, hypothesis driven execution, outcome-oriented thinking) are missing.

    The Fix.  
    Understand where the skill deficit is by comparing your product owners against the Product Owner Core Skills Matrix.  Engage in self-paced just in time practical training, such as “How to Build Your Backlog From Scratch.”
  • Unclear role.  While the title product manager (or product owner) suggests some amount of business or product ownership, product managers often function as glorified business analysts.  Rather than having any ownership of real business outcomes, product managers are put in place to run interference on behalf of the business (document requirements).  This leads to frustrated teams, frustrated stakeholders, and unempowered product managers.The Fix.  Rather than rely on the boilerplate you copied from monster.com, take a fresh look at the role, responsibilities, and expectations of your product managers.  Here is a template to help you.
  • Business objective blindness.  While product managers are supposed to represent the business and their needs, product managers are often kept out of key conversations and don’t have the visibility into the organizations overall strategies, goals, and objectives.  This makes it difficult, if not impossible, to tie product management decisions to overall business objectives.  If product management decisions are not tied to business objectives, what’s the point of having product managers?The Fix.  Invite your product managers to strategic leadership meetings.  This way they can be aligned with the broader business goals.  This means less hand-holding when it comes to articulating problems to be solved, and greater stakeholder satisfaction.

shutterstock_133198406

The goal is overall business agility

Your process  that takes an idea from concept to cash is only as strong as its weakest part.  The weakest link is most often not your technology teams, but its the easiest to attack because the costs are visible and the outputs are sub-optimal.  The purpose of agility is to improve business outcomes, and your product managers connect business outcomes to product development process and the software development teams.

As an idea is formulated, improved, developed, released, and monetized, make sure you take a look at the complete cycle.  Where are the bottlenecks?  Where are the miscues?  Where are there opportunities to improve?  The software development aspect is a small part of the end to end value chain.  Make sure you look at your business cases, how you prove ROI, how to run product marketing experiments, and how to engage in effective customer development.

Until Next Time,

Stay Agile, My Friends

Tirrell Payton is the principal at Payton Consulting, a San Diego-based boutique consulting firm that helps companies improve their technology capability to match their business ambitions.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Every Company is a Technology Company

The Shocking Truth: Why Every Company Is a Technology Company

When I step foot into a company, one of the first questions I ask leadership is, “What does this company do?” Not because I haven’t done my research on the background of the company, but because I want to hear from them what they think they’re in the business of doing.

The normal ones say, “We’re an ecommerce company” or “We’re an apparel company” or “We’re a fashion brand” or maybe, “We are a biotechnology company.” The smart ones will say something to the effect of, “We’re a technology company that happens to sell health insurance.” In this article I will outline 4 reasons every company should have this same mindset and consider itself a technology company.

Customer expectations are different in a digital-first world

Whether your products are consumer products or you operate business to business, customer expectations are different in this new digital first world. One of the reasons for this is the continuing cross-pollination of consumer technology and business technology.

Back in the day, consumer technology would be considered a “toy” by any serious enterprise technologist. These days, most of the leading edge methods and practices being adopted in enterprise technology come from the consumer world. Whether it be mobile, social or advances in design and interaction, there is a lot more crossover between consumer technology and business technology.

This may seem irrelevant; but you have to remember that your strategic partners, your customers and even your employees operate in this consumer world as well. Therefore, customers expect their services and experiences to be customized and personal. This creates a huge opportunity to create value by meeting their needs, but it will require an updated more flexible execution model. Technology systems will need to be more lean and flexible to fully take advantage of new opportunities.

The competitive landscape continues to accelerate

This has been true for years, but the trap companies sometimes fall into is to think that this is a temporary event, and “once this all blows over” they will be able to go back to “business as usual.”

Acceleration is business as usual, and this means companies will need to be able to rapidly adopt, integrate and deploy new technologies more quickly than their competitors. Everyone looks at the stories of Kodak, Blockbuster and Research in Motion (RIM). When they see the fates of these companies they think, “That could never happen to us.” They said the same thing.

These companies were faced with a changing landscape, but they were so wedded to their current business model they could not see how the changes would affect them. On one hand, they didn’t want to cannibalize their existing business model in favor of something that may have been a temporary fad. On the other hand, these companies were so massive, that changing would require a 5-10 year effort. What do you do in this situation? I generally advise companies to make “1 small bet each quarter, and if that turns out to be a winner, put more resources into it.”

In this new landscape companies have to not only manage current business but also continually probe new models in a systematic way. This means being able to rapidly develop solutions and infrastructure to explore a problem space, then rapidly ramp up if the opportunity turns out to be significant.

Product lifecycles are shortening

With software and technology continuing to change every aspect of how companies operate, the life cycles of products and services are shortening. Products that used to have decade-long refresh timelines now get updated within 12-24 months.

Services like sales, marketing, legal, product development and merchandising have to be agile enough to react in tandem to emerging opportunities. A big part of creating this agility cross-departmentally is having software and technology systems that enhance everyone’s ability to react to change.

Operational capability is tied to technology capability

A big trend in the last decade was outsourcing whereby a company would outsource large parts of their software development and technology implementation to a third party. CFOs everywhere cheered this as a way to unlock enterprise value.

Unfortunately, the honeymoon does not last long, and companies who have sliced their internal technology capabilities to the bone are finding themselves locked into multi-year outsourcing agreements and unable to react quickly to threats and opportunities in the marketplace. These agreements have a defined scope and any change means you have to revisit the contract process, which no one wants to do.

The most successful and highest performing companies have little separation between their business strategy and their technology strategy. In short, they have technology as part of their DNA, and they would NEVER outsource this significant competitive advantage. Companies who realize they are in the technology business can drive speed and innovation by closely aligning their technology leaders with their line of business leaders to co-create solutions.

I work with a lot of companies across industries and all of them have a few things in common:

  • They are in various states of digital transition.
  • They are trying to make sense of rapidly changing demographic trends.
  • Things that were leading edge just 5 years ago no longer work well.

One of the mindsets I work really hard to change is that their transformation is a destination. In fact it’s a never-ending journey of continuous improvement, continuous innovation, and continuous experimentation. Companies who are able to successfully create internal “engines of innovation” are positioned to continually evolve and stay competitive.

Until Next Time
Stay Agile, My Friends

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Announcing: The Ultimate Guide to Building Your Backlog

Cover8x11_115

I took 8 years of backlog building experience and stuffed it into a new and exciting book and course.

This was created because I saw so many product owners struggle with building backlogs.  When I would work with new teams, they would be excited for the possibility of what Agile could bring, but that excitement soon would turn to horror as the team was forced to try to consume backlogs in horrible condition.

Imagine buying a brand new house only to find the foundation was cracked, the beams were rotten, there were mice living in the walls, and termites were eating the roof.

This is what a poorly created backlog feels like to a new team.  A team that is forced to work like this will be demoralized and demotivated.  It certainly does not set the stage for a productive, excited, engaged team.

This material will show to take all the thoughts and information in your head and create a crisp, clean, prioritized backlog for your team.  You will be able to smoothly negotiate the rough spots with your team and stakeholders?

It’s not just about “building your backlog” — it’s about making your stakeholders and teams happier, which in turn makes you more respected by them and gives you the reputation as the go-to person when the stakes are high and the project is important.

My comprehensive workbook is guaranteed to help you totally transform how you build backlogs, or I’ll refund you in full.

Click here to get it


There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why you should give your teams problems to solve, not solutions to implement

In my role as a consultant, part of what I do is observe problems. Here are some of the problems I observe:
– Technology leaders stressed out, banging their heads to find solutions to difficult business problems.
– Technology teams not fully engaged, waiting for the next “unrealistic thing to implement in an unreasonable timeline” from leadership. – Customers who don’t feel like their success is at the core of how their service providers do business.

In this article I will explore the practice of giving problems to the team to solve, rather than solutions to implement and how it improves leadership’s leverage, teams’ engagement, and customer satisfaction.

The secret of leverage

Here is the dirty little secret of business, “Leverage is the difference between effective leadership and ineffective leadership.” What I mean by leverage, specifically, is the art of using resources around you to multiply the impact of your strategies and execution.

How this applies is that most technology leaders became leaders because they were good at technology. In fact, most of them were so good they were promoted. So they are used to being the person with the answers, able to create elegant solutions to difficult problems.

Its not your job to be the smartest guy in the room

However, when you move to a position of leadership, its no longer your job to be the smartest guy in the room. Its your job to create teams of people who are smarter than you. Why? So you can leverage their intelligence. 10 smart people looking at a problem will envision a wider range of acceptable solutions.

Pro tip: Don’t keep the problem space to yourself in your head. Explain to your teams the top 3 business problems you and the rest of the leadership are trying to solve.

Engaged employees don’t need to be told to work hard

Have you ever had those moments where you just fall into the flow? Where the direct line from your creativity and your logic just meld together into an ever-satisfying melange of bright shiny goodness? I’m sure you have. This is what being fully engaged feels like. Unfortunately, most of your teams are not fully engaged.

They aren’t fully engaged because no one is engaging them to actually help solve problems. I talk to countless numbers of front line workers and middle management and a lot of them have the same complaint, “Leadership goes off and comes up with some hair-brained solution on an unrealistic timeline and we’re supposed to make it happen.” This is a source of frustration and even worse, a source of disengagement.

Pro tip: Involve some of the members of your teams into your high-level planning sessions, ask their opinions, and really consider their input. People are more likely to buy into a solution they helped co-create.

Your customers are why you’re in business

The very core of what you do is to solve problems your customers are willing to pay to have solved, but your customers problems may not permeate beyond the “business development” layer of your organization.

Its important to keep the “customer mission” at the top of mind when engaging your problem solvers. Helping everyone understand the customers’ problems means that we reduce the risk of “a solution looking for a problem.”

Pro tip: Make sure the understanding of customers problems’ extend beyond sales and marketing into the technical teams mindsets.

Better customer engagement, better employee engagement, better solutions overall.

Whats not to like? You’re in business to serve your customers, and technical teams are technical because they like to solve problems. Lucky for you, that fits right in line with the core mission of your business. Give your teams problems to solve rather than solutions to implement, you will be amazed at the results

Until Next Time, Stay Agile, My Friends

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More