Tag: Development

Leadership Lessons: Implementing Change – Phase 4 – Create Desire to Change

Written by Peter de Jager on November 10, 2015. Posted in Articles. 1 Comment on Leadership Lessons: Implementing Change – Phase 4 – Create Desire to Change

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1, phase 2, and phase 3. Check back every week to read the next phase.

“A body at rest will remain at rest until acted upon by an outside force.”

That’s as much an observation about people as it is about physics. If there are no outside forces, then nothing changes. Sometimes the ‘key’ to change is nothing more than making people aware of the outside forces. One of the downsides of the status quo is that it lulls us into a false sense of security and we need to be shaken awake in order to change.

What Problems exist in Status Quo?

Nothing is ever perfect, that includes the current status quo. The imperfections in the status quo, create points of leverage that can help move a change forward. What is it about the current situation that has been a well known hindrance in the past? How dissatisfied is the target audience with the status quo? What exactly causes that dissatisfaction? If you don’t know the answer, ask the target audience – they do, in great, exacting, painful detail.

What are the alternatives?

What alternatives are there to the current status quo? There is always more than one way to do things. Why did we choose this particular status quo? What other options did we have? What other options can we create? Does it really matter, in the long run, which option we choose? If not, if they are all relatively equal, why can’t the target audience choose which one they should move to?

What are personal Benefits to Changing?

Just as there are always problems with the current status quo, there will also be benefits in any new situation. It’s a useful exercise to help the target audience to list those personal benefits.

What problems would Change Solve?

Will the change being proposed solve existing problems? How? If not, why not? It is a mistake to think everyone involved in the change sees all the benefits of the change. It’s perhaps a tedious task to list the benefits, it’s also very beneficial to those who may not fully understand all the implications of the change. It’s difficult to communicate enough during change; it’s impossible to communicate ‘too much’.

What core values would Change reinforce?

What, out of everything the current status quo provides, will be reinforced by the proposed change? This is another way of communicating what will stay the same, only more so. This is surprisingly, a very powerful bit of information. People need stability, and knowing what won’t change in the coming months will offer more solace in the face of chaos than you might expect.

What opportunities would Change Create?

Change is not just about escaping problems in the existing status quo. It should also be about creating an environment of new opportunities. Do not assume the target audience can see those opportunities without being told, informed, communicated to etc. The primary task of the Change Inflictor is one of a communicator. Informing and re-informing people of what is going on and why.

Your Backlog Might Be Broken If…Part 1

Written by Angela Wick on October 13, 2015. Posted in Articles.

How does your team build and manage their backlog? Is your current process working well or does your backlog need a reboot?

One of the most overlooked factors of team success or failure is the health the backlog. Success or failure often hinges on the amount of love and attention an organization gives to their queue of needs, features, feedback, bugs, and enhancements.

I am concerned that teams and organizations continue to focus too much on getting items developed faster vs. developing the right items—the items that add the most value to the organization. Traditional and Agile teams alike are experiencing these challenges.

Poor backlog management yields inefficient and ineffective projects/iterations/sprints/releases, and ultimately less value delivered overall. If you neglect your backlog and let it wander off, unattended, into the crowded project circus, it will dart to and fro distracted by every bright shiny object. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn and value will be lost.

Successful teams give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve, but the overall goals and objectives are clear, the process is transparent, and teams gain efficiency.

Strong backlog management practices:

Keep teams focused
Deliver value quickly
Inspire innovation and creativity
Mitigate negative risk

It can be quite difficult for organizations to assess objectively the health of their backlog management processes and even more difficult to implement changes. These processes are often unwritten and entrenched years of evolving organizational politics, culture, and values. But admitting you have a problem is always the first step, so I’ve identified a few indicators that might shine a light on your broken backlog. Read and ponder the first two indicators this month and I’ll give you a few more to think about in Part 2 next month!

Related Article: 7 Habits of Highly Effective Business Analysts

Your backlog might be broken if…it is not prioritized.

How does your backlog get prioritized? What criteria are used? A healthy backlog delivers only the right work at the right time to the team. The most important things need to slide to the top and should be prioritized by value to the organization.

Prioritizing the backlog in traditional and Agile environments entails elicitation, analysis, and decision-making. As BAs and PMs, we may be the one facilitating this process, or as Product Owners we may own the decisions on the priorities. Either way, it’s our job to keep the development stream clean! Only items that yield true value to the organization should flow into development. We use tried and true analysis and elicitation techniques to ensure that each item is understood from an end-user and organizational perspective so it can be effectively prioritized.

If you are like many organizations your backlog may be 100s if not 1000s of items long. That seems impossible to prioritize! So, how do you deal with a backlog that is simply too long? Here are a few ideas:

Make sure the backlog is not just something the technical team is managing; it needs to be aligned with the business. The right business drivers should guide the backlog prioritization.
The top 10 (or about 10) items should be known and rank prioritized by value
When an item hits the top 10, elaborate additional details and requirements
The rest of the backlog can be grouped into like categories. Please do not categorize them by technical application, component or task, but rather by feature, process, or something of tangible business value that is understandable to the business decision makers.
Revisit the top 10 as often as needed to always have a top 10 in place.
Track the time something has been in the backlog…. seriously consider deleting/archiving the item if it remains in the backlog and not making the top 10 for six months (or whatever timeframe seems appropriate).
Make sure everyone knows the top 10 ranked priorities and get everyone focused on #1!

Warning: If your team seems to be using FIFO (first in first out) or SWGG (squeaky wheel gets the grease) processes for backlog management, the team is at high risk for not delivering value and spending the organizations resources appropriately.

Your backlog might be broken if…it is inside out.

Does your backlog focus inside out (technology and technical tasks) or outside in (user and business point of view)?

Backlog items should be written from the user or business perspective, NOT from the perspective of the team or the technology components. A piece of technology, all by itself, does not typically provide value to the user, especially in our complex integrated environments.

To prioritize the backlog we need to understand the value each item provides by writing our backlog items in ways that express the value to the organization, end customer or end user.

When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience. If your backlog items have names like “code profile page” or “write SQL for DB call” or “map data for credit card validation,” your backlog might be broken.

Backlog items should express the WHO, WHAT, and WHY, in terms that the end customer understands and can be prioritized by business leaders.

Some ideas to transition poorly written backlog items:

Item 1: Add a SAVE button at the bottom of the screen.

Rewritten: Give the customers the ability to save an order mid-stream while entering all of the order data so that they do not risk losing information already entered if they step away or get interrupted while entering.

Item 2: Upgrade the database to the new version

Rewritten: For customers to be able to enter orders after Oct 1st, 2015 we need to upgrade the database to the new version so that the version works on the operating system.

Item 3: Code the server file to add the new volume properties

Rewritten: To serve our expanding customer volumes we need to update the server file to accommodate more users at one time.

Is your backlog broken?

As you evaluate your backlog this month, ask yourself these important questions:

• How are our priorities really being determined?
• Are the items on our backlog written in a way that makes it easy to understand value and identify priorities?

Our backlog health check will continue next month when I share a few more “broken backlog” indicators in part two of this article!

Why the Scrum Product Owner IS a Project Manager, part-2

Written by Robert Galen on August 4, 2015. Posted in Articles.

In the first part of this post we began to explore the Project Management quadrant of my 4-Quadrants of Product Ownership model. When I introduced the 4-Quadrants in this post or blog post, I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:

1. Product Management
2. Project Management
3. Leadership
4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Manager area. I think because many had a view to traditional project managers they’d worked with in the past, and they were having trouble mapping these skills into the role of Product Owner.

Next I’ll continue the deep- dive exploration of aspects of that quadrant, with three more areas:

5) End-to-End Project Release Planning

One of the central activities of SAFe is conducting a 2-day PSI (Potentially Shippable Increment or Release Train) planning session as a team. The event is focused on mapping work (Epics & Themes) or the “ask” from a business perspective to each teams’ ability to commit to User Stories that meet the ask.

The planning takes an end-to-end view, so from:

Requirements and visualization
Architecture – system, UX, DevOps
Through construction
Testing (functional, non-functional, automation development)
Covering operational readiness (DevOps deployment, documentation, training, customer readiness, etc.)
Deployment to Production

In other words, it takes a “Concept-to-Cash” view to ALL of the work required to deliver on the goals, themes, and features for the release. And keep in mind that the PSI is planned in a series of sprint-level increments, so it is an iterative plan.

In SAFe, there is a role entitled Release Train Engineer or RTE. They are largely responsible for facilitating and orchestrating an effective PSI-planning event.

Even if you’re not implementing the SAFe framework, many Agile organizations and teams leverage some sort of release-level planning activity—particularly in at-scale Agile. It just makes sense to have a view to a larger picture before letting loose multiple Agile teams towards an unplanned goal.

I would argue that the individual Product Owners and the Chief Product Owner are incredibly important to effective release planning. Not only to “set the stage” with the “ask”, but to be there during the planning to answer questions and to help the teams make appropriate scope tradeoffs as they try and deliver on your goals.

I would even say that Product Owners should become “students of” release planning techniques, approaches, and models. Even with an RTE or similar role, you’ll want to partner with them to ensure you and your teams have a solid plan. Here’s a link to a PDF article that explore various forms of release planning in much more detail.

6) Stakeholder Management

I remember distinctly in traditional projects where our C-level team would “call in” the project managers for portfolio level tracking. Often they would never see or interact with the individual teams. Instead, the project managers were the sole lenses for each project.

This placed a tremendous burden on the project managers to effectively “manage” stakeholder information sharing, expectations, and their reactions. Some were good at it and others were not. Some had more trust with stakeholders, which mattered a great deal too.

Often you could draw a direct correlation between projects that were going well versus not, by the maturity and skill of their project managers stakeholder management.

As we move to Agile contexts, this sort of stakeholder management is still largely relevant, but now it falls to Product Ownership to handle expectations management. Often it focuses on reinforcing the importance of your Stakeholders and Senior Leadership to “fully engage” with your/their Agile practices.

For example, getting them to regularly attend sprint demo’s, release planning, Scrum of Scrums meetings, and even circulating around daily Scrums will give them a strong sense for progress, challenges, and where they might help.

But you’ll still need to provide a “buffer” between your teams and your stakeholders, so that they effectively understand and react well to the transparency and the adjustments being made.

Note: this crosses into the Leadership Quadrant of the 4-Quadrants to some degree. This is one of those nuanced areas that really make a difference in your overall success. I often challenge the Chief Product Owner (or other Product leaders) to think about who and how they’ll be thoughtfully and actively managing their stakeholders.

7) Project Retrospective

Clearly you’re involved in each sprint retrospective that your teams conduct. And I want to encourage you to fully engage in each one of them. But that being said, I also think you need to take your feedback acquisition “up a level”.

Your Sprint Reviews are a wonderful ceremony to gather feedback from your Stakeholders and Leaders. Please don’t miss that opportunity to gather their feedback as you deliver each increment. And don’t always assume that you’re getting it either. I’ll share a story to make that point.

I was talkin Software Devg to the EVP ofelopment at a conference not that long ago. He was describing the interaction in a recent Sprint Review or Demo. He said:

Bob, I threw a 5 to represent my reaction to the demo, but I wanted to throw a 2. In truth, the demo was terrible and I believe the team failed to meet customer needs in their development efforts. I just felt very uncomfortable giving that sort of negative feedback in front of a large audience. I pulled aside the Director of that team later, and I gave her my feedback.

I actually challenged him to speak the truth” in future reviews. I tried to make the point that it was important to be transparent with feedback as well. Sure, craft it carefully, but if a demo sucked and you said it was great, that is setting a very bad precedent. He responded:

You’re right Bob, but we are located in the South and have a culture of thoughtfulness and care when giving bad news. It will take me (and us) time to get over this cultural barrier. But I can’t imagine “telling truth” for quite some time.

Clearly you need to work incredibly hard to get all forms and types of feedback out from your stakeholders. Be aware of your cultural norms and figure out creative ways to get the truth on the table so you and your teams can address any deficiencies or misses.

SAFe has a release-level retrospective at the end of each PSI. It’s a cross-team, ALL stakeholder meeting where issues are discussed and improvement action-plans are formed. So there are multiple “layers” to the feedback and reflection opportunities.

I’ve written several other posts that explore the power of Sprint Reviews beyond simply showing software:

• http://www.projecttimes.com/robert-galen/the-agile-project-manager%E2%80%94voila-the-great-reveal.html
• http://www.batimes.com/robert-galen/sprint-reviews-learnings-from-the-movies.html

I wanted to remind you of one of the reasons I developed the 4-Quadrants in the first place. It’s because of how hard the Product Owner role is to perform well. It’s an incredibly deep and broad role that requires tremendous effort and skill. It also requires quite a bit of time.

I often joke, and it’s not really a joke, that I’ve only met 4-5 Product Owners who could perform all aspects of the 4-Quadrants by themselves. Ever! What this implies is that it’s OK to ask for help. In fact, you’ll most probably need to get help in your role.

If you have Project Management strengths and skills, then take some of this on yourself. If you don’t, then look for someone else in the organization with these skills and strengths to help you out. For example, in SAFe environments, you might want to make the RTE a partner or best friend.

But the KEY is to find or ask for help if you need it in the quadrants where you are weakest.

Wrapping Up

I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. But whether you like the 4-Quadrants model or not, this work is there for you regardless. The key is to be aware of it, get someone covering it, and to do it very well.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve shown you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,
Bob.

You Don’t Know Jack

Written by Mike Lenz on February 9, 2015. Posted in Articles. 1 Comment on You Don’t Know Jack

A healthy respect for the magnitude of what we don’t know

Every time I start to believe I’m building an expertise in something or starting to mature into an experienced “adult”, life has a way of smacking me in the head and reminding me that “I don’t know jack.”

In general, the word “expert” has always stuck out to me. What does that word mean? I’ve always thought of it as “you know everything”. So for me, to be an expert on something is an insane achievement. You know everything? That’s crazy.

I have a hard time even imagining the reality of knowing everything about something. Under that definition, I’m not even close to an expert on anything. Often when browsing Twitter I’m exposed to so many new ideas, new topics, new thoughts that the sheer volume of shit I don’t know can be overwhelming. Even a single topic. Pick one thing. Can you know everything about even that single topic? I don’t know.

But we don’t need to know everything to contribute. Each of us as individuals adds our own unique value from the perspective of our own unique set of knowledge. No one else on the planet has the exact same combination of experience and knowledge, and the pursuit of improving that collection is called Life.

In my opinion, more important than the depth of a person’s knowledge is their self-awareness of what they don’t know. Am I an expert on Digital Marketing Platforms, Content Management Systems, or Adobe Experience Manager implementations? I wouldn’t use the word “expert”.

However, I would happily match myself up against anyone else in terms of ability to lead and execute an enterprise digital marketing platform implementation. I have depth of experience and knowledge on the topic, but more importantly I know what I don’t know. I approach each new engagement with a healthy curiosity and eagerness to find new challenging problems to solve.

The reality that there’s so much still to learn is what makes each day so exciting. So yes, I don’t know shit and neither do you, but that’s what makes life worth living.

So let’s learn something today and remain humble to the reality that there’s always so much more left to learn tomorrow.

Don’t forget to leave your comments below.

Not Just another Visio Diagram

Written by Kim Quirke on February 2, 2015. Posted in Articles.

Last year I had the opportunity to attend a course by Penny Pullan called Creative Facilitation. It was a course with heaps of practical tips around how to add creativity to the way you facilitate and present information. It was during this course that I had one of the those light bulb moments; adding creativity to how I facilitated meetings was great, but it was the idea that I could also apply this creativity to other business analysis tasks that got me really excited.

The problem that I had was that the process diagrams I was drawing for my business customers weren’t very engaging. They had all the traits of a good process diagrams with boxes and lines showing me step by step through a business process, but they still looked like boxes and lines with maybe some colour to spice things up. They weren’t something that was exciting for the business to look at and also not that exciting to create. I really wanted my customer to be able to look at the diagram and see themselves in the business process and give them confidence that we understood them or were well on our way to understanding them.

The course changed things for me – not only was it ok to be creative in areas that aren’t typically seen as creative, but, more importantly, they also provided some really easy techniques for drawing people, people who could do stuff, people who I could draw in seconds. We have all seen the business analysis methodologies that love stickmen, but to me they always look like they have been drawn by a kid – they were boring and they didn’t do anything. By using a squiggle or a box for the body instead of a line, my person could be riding a bike, sitting at a computer or jumping in the air.

The magic for me happened when I replaced my Visio boxes with these pictures and I didn’t need to spend ages scouring the internet for random pictures, which lacked consistency of style or feel.

Before:

After:

Suddenly my picture didn’t just show a process, it now told a story to the customer, the story about ‘their’ business and how ‘they’ interacted with their business. It helped add context to changes being proposed and what the likely impact would be, not only on the business process but also the people involved in that process. Most importantly the customers were keen to interact with the picture and show me what they thought.

More interesting for me was the feedback I got from other BA’s and technical staff. Quite a few people who were Visio savvy and created these types of diagrams didn’t like Visio diagrams, which are often seen as ‘IT’ diagrams. Adding the pictures has removed the ‘IT’ feel and my customer has requested that other people use this technique when creating their business process diagrams.

For me, this has given me the confidence to start adding creativity into all the diagrams that I create, while reinforcing what I already knew about most people being visual and wanting some emotional connection to what they read.
What are some of the ways that you like to add creativity to your everyday and help delight your customers?

Don’t forget to leave your comments below.