Skip to main content

Tag: Training

Leadership Lessons – Change in Seven Questions

What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate! 

How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water, and we start all over again.

Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.

This isn’t exactly news. We sort of get this. Ask any audience to tell you the secret to good Change and they will repeat back “Communicate, Communicate, and Communicate some more!” as if it was forcefully injected into their cerebellum. The problem arises when the questioning becomes a bit more detailed, “What exactly should we communicate?”

The response to that question is usually either a blank stare or the reasonable recitation of the reporter’s standby; Who, What, Where, When, How and Why. Not a bad start. If you’re writing a news article, then these are good solid questions. The Change Management problem requires all of those, and a few others besides. It’s not that the reporter’s questions are a poor tool; it’s just that they don’t address the peculiar psychology of the Change challenge.

For what it’s worth, here’s a carefully selected list of questions specific to Change Management. If we take the time to answer these, then we’ve covered the bulk of the key concerns of those facing the Change we’re contemplating.

1) Why?

This is the winner, the key question; it’s almost the only question worth discussing. If someone asks me to move from one side of the room to the other, or to stop using system ‘X’ instead of system ‘Y’, my response is always the same. “Why?” Understanding why a Change is necessary is the most important question we have about any Change. Without a good answer, we’re reluctant to do anything different.

There are lots of good answers to the “Why?” question. One good one is “Trust”. If I trust you and you ask me to do something, my trust in you might be sufficient to prompt me to Change. If that trust doesn’t exist? Then the reason for Change had better convince me, or I’m not moving from where I am.

2) WIIFM (What’s in it for me?)

The fly in the ointment for many organizations, “It’s not about you!” they cry as they bend over backward to avoid answering this question. Here’s the newsflash, as long as they are concerned about the WIIFM question, they don’t pay attention to any other information. More precisely, until that WIIFM question is answered, they can’t pay attention to anything else.

The best way to think of the WIIFM question is as a nasty, vicious guard dog, blocking the gate to our attention. Until that dog is thrown a bone, no information about the Change, sometimes not even the answers to the “Why?” question, is getting through to our reasoning process.
Even if we honestly have no information about the WIIFM question we must still acknowledge that the question exists and that as soon as we do have more information, we’ll get back to the audience.

3) Monday?

Assume, for the moment, we have returned from our strategic planning weekend with a wondrous, phenomenal vision of the future of our organization. Also assume, for the moment, that our ability to convince everyone that this is indeed the direction in which our organization should move, is up to the task. Assume that we’re silver tongued devils and get everyone on board, on the bus, bought in and generally all fired up. With me so far?

Now they have a question. What do we do differently, specifically and precisely on Monday (or next Friday…or next month… ) to start moving us towards the promised land of milk and ever flowing honey?

It’s a fair question. If we want people to Change, we must describe what they’re going to do differently in terms that everyone can understand. If we can’t, then we go back to the drawing board, our vision is flawed and unattainable.

4) Won’t?

What won’t Change? What will remain the same during this Change?

The problem here is that when we face a Change, all we see are the unknowns, we lose sight of the fact that only one ‘small’ part of our status quo is going to flux. That the rest of our surroundings will likely remain the same.

For example? When the accounting system is going to Change, we’re still going to report to the same boss, earn the same paycheque, receive the same benefits etc. In fact, most of our status quo will remain the same. This works for nearly all Change, the only time everything Changes is when we die, and then? It’s not our problem anymore. In nearly all other cases regardless of the size of the Change, nearly everything else remains the same.

5) Might?

What might go wrong during this Change? And what contingency plans have we put in place to mitigate those risks?

The worst thing we can do when heading into the uncertainty of Change is to insist that nothing can go wrong. That’s not only asking for the Gods to pay attention to us, but it also communicates to those around us that we haven’t really thought this through. Although if we’re looking for a sure-fire way to lose the trust of those who follow us, insisting, “Nothing will go wrong” is a wonderfully effective strategy.

6) Will?

What’s going to hurt?

Change hurts. That’s almost the ‘First Law of Change’. If we’re doing something significantly different, then we’re going to be at the bottom of the learning curve. Even if we pay close attention to training and support and fall back positions, we’re going to make mistakes, production will decline, and we’ll get things wrong. If we pretend that the Change will be painless, that it will be “transparent to the user”, then people will know we’re lying, or at least overly optimistic. 

7) Signposts?

Change doesn’t always happen quickly, sometimes it’s slow, almost glacial in nature – we need some way of measuring our progress towards a goal. Without feedback we lose both the motivation and the will to make sacrifices to move forward. The question on the table is, “How do we know we’re succeeding in our efforts?”

These aren’t the only questions we need to answer during a Change, but they’re crucial ones and if the answers aren’t forthcoming, neither will the Change. Stick them on the wall in front of you when crafting a Change message and ask, “Am I answering these? If not? Why Not?”

© 2015 Peter de Jager – Reprinted with Permission. 

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

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.

Leadership Lessons – When Were you Last Engaged?

No. That isn’t a question about your personal life, it’s a question about your work life. Are you still engaged? Or has the passion for your work worn off? More to the point? Are our staff still engaged? Do they look forward to arriving at the office, or are they regularly having to buy new alarm clocks because the old ones don’t hold up to the Monday morning mauling to shut them up?

The issue of ’employee engagement’ has become a bit of a trend lately. Head to Google Trends (www.google.com/trends) and type in ‘Employee Engagement’ for a visual representation of that trend based on Google searches. (Compare it to how my specialty of ‘Change Management’ is trending. Oops. Do I need to change my topic?)

The first thing we need to do is define what we’re talking about. What is ‘Employee Engagement’ and then, why should we care about it.

Here’s a definition I use that’s in synch with what I’ve seen as common usage;
“ an employee who is engaged with their job feels a certain amount of ownership in the outcome of their actions, they care about their work, they show initiative when something needs doing, rather than waiting for someone to point them in the right direction”.

Why is it important? Consider yours truly, the writer of this column as an absurd example. I’m a one man company. I must be engaged in what I do, not necessarily all of what I do, but at the very least with the core of what I do, otherwise there are ugly consequences.

I could not care less about ‘accounting’, yet it must be done – so I outsource that administrivia, and several others, to someone else. Problem solved.
But, the core of what I do is ‘take the stage’. The instant that becomes a chore, something I do on autopilot because I have to? Then I am on the fast path to being an ex-speaker.

In a typical office, the consequences of lack of engagement are similar, but they are easier to hide, or at least to ignore. A single unengaged employee out of a staff of 5 or 10 might be regarded as not much of a problem, but if 50% of staff are unengaged, then productivity and quality begin a precipitous drop.
If all of our staff are disengaged from what they do, then who owns all that which needs doing? Who cares about the deliverable? Who takes the initiative? If ownership, caring, and initiative is all falling to a handful or even a single individual? Then we have a serious problem. Especially when increased ownership, caring and initiative without recognition and/or reward is a very good reason to stop caring… anyone for a good game of domino effects?

When employees become disengaged, then even day-to-day operations require conscious effort to drive them forward, an effort that might be better used thinking about tomorrow.
So why do we disengage? Here are five possible reasons – there are others.

  • Not enough feedback.

We’re simple creatures. We like to know how we’re doing. Without feedback? We have no clue if we’re going in the right direction. Feedback is food that feeds our motivation.

  • Lack of opportunity to grow

We also don’t like standing in the same place, at the very least most of us find that boring. Even if there are no new positions to move into, are there at least new things we could be doing?

  •  Lack of recognition

This boils down to a simple question? Do you care that I care? Not everyone is ‘self-motivated’, many us, make that nearly all of us, appreciate being appreciated.

Here’s a challenge. I dare you to do this. One Friday afternoon. Order in a few pizzas, some cans of pop, some dessert. Call everyone into your office and tell them, “I know you’ve all been working hard. I just wanted to say. “Thanks!” You don’t have to say anything else. Just ‘Thanks!’ This works even better if you’ve never done such a wild and crazy thing, especially if your organization has banned office celebrations. (This must be the case, because office parties have become a rare beastie.)

Let me know what happened. My e-mail is at the end of this collection of articles.

  •  Lack of Trust

I don’t think anyone needs to spend much time elaborating on this. Nobody cares to put extra effort into an organization they no longer Trust. On a scale of 1-10… how much Trust is there in your organization?

  • Stress-Burnout.

Things are tough all over and getting tougher. If you want to muse something over on your own? Go back to Google Trends and do a search on ‘Recession’…. compare that chart to the one you got when you searched on ‘Employee Engagement’.

Not all of the above are solved easily, some are, others are way beyond our scope and powers. The problem of employee disengagement is a real one. If allowed to grow (or encouraged to grow!) then sooner or later the organization is coasting (grinding?) to a halt. The first step in solving it is accepting that it is a problem… and with that? Here’s the closer;

Here’s a personal question.. What do you do on autopilot at work? What have you disengaged from? What have your staff disengaged from? What’s that costing your organization? Do you know? Do you care? (Careful with that last answer… it’s a doozie) 

© 2015 Peter de Jager – Reprinted with Permission.

Why Does my Development Project Need a Business Analyst?

The short answer: Because you want a project delivered on time, meets your specifications, and works for the end customers.

The long answer: The following project is a real example to illustrate the missing pieces and how a business analyst could have made a huge impact. Do you see similarities with a project you have?

Background

A team member (let’s call him Guy) worked with the client managing multiple Excel spreadsheets. Guy saw a pain point and realized he could do something about it. He suggested building a web application with relational databases to help the team. The client liked this idea because they realized this new tool would impact forecasting and reporting – affecting the bottom line.

Guy set to work with the client outlining the project and developing the tool. A talented project manager (Pam) joined the project. Despite Guy’s knowledge of the business process and technical skills and Pam’s attention to detail, this product was behind schedule. The end customers found that this tool relieved some pain points but didn’t address all of their needs or use cases.

What happened?

Why did a product that started out so promising end behind schedule and not fully addressing the end customers’ need?
Simply put, because there was no business analyst. Guy spent his time working with the client to understand the use cases instead of developing the tool. Pam spent the majority of her time collecting the requirements from the client. No one talked to the end customers. The only requirements provided where the “Shalls” included in the contract that did not cover the full scope of the tool. And most importantly, no one ensured Guy spent his time developing instead of gathering user stories.

What does a business analyst provide?

The most important value a business analyst provides is getting the right information to the software developer in the right manner. The business analyst works with the team to make sure the product delivered fits their needs. In this case, a business analyst allows the developer to focus on developing code.

Business analysts bring:
• An understanding of the business needs and the client needs
• A full understanding of user stories and use cases for the end customer
• Detailed requirements translating the customer needs into technical tasks
• Clear communication with the developer to create the right tool
• Detailed work with the project manager to confirm deliverables are on time and meet the contractual obligations

Wrap up

So why should I spend extra money for a business analyst? Because omitting this crucial team player will cost me in time and quality of the final product.

Do you have an example of a project that succeeded because of a business analyst’s work? Do you have a project that could have been better with the help of a business analyst?

Better Tools: Efficient Table Management

As a Business Analyst, I know that models and diagrams are the most effective way of expressing ideas, information, and outcomes. However, no matter how much I use visual content, I am often required to prepare text-heavy documents.

Whether it is requirements statements, business cases, service levels, project reports or dozens of other documents, sometimes I need to prepare written content as efficiently as possible.

To present written content, I try to maximise my use of tables, typically using Microsoft Word. I found the that the standard table tools in Word were not as efficient as I needed, so I set out to address these deficiencies.

This article outlines my thoughts on why tables are so effective, and indicates the improvements that I have made to Word’s table management features. I then describe the techniques I used to build them, and provide a link where you can find further details and copies of each of the tools.

What Tables Offer

From a BA perspective, I believe tables provide the following benefits:

Item Feature Comment
1 Conciseness
  • The limited space in a table drives a focus on recording key information. Unnecessary content is discouraged.
  • Bullet points are encouraged.
  • Short phrases, possibly ungrammatical, can be used.
2 Usability
  • Readers are much more likely to scan a table; large amounts of information can be viewed at a glance.
  • Tables also allow the reader to spot patterns and search for detail that would otherwise be lost in regular text.
  • Tables focus attention onto the key points on the page.
3 Context
  • The column and row headings provide context to table entries that would be lengthy and repetitive to record in regular text.
4 Structure
  • The order of rows and their presence in particular sections conveys important structural information.
  • Numbering rows aids the review process and provides traceability.
5 Speed
  • Tables allow information to be captured and formatted quickly. This is important for BAs working to deadlines.

Renumbering Improvements

For me, the main issue with Word’s standard tools was the lack automated row renumbering. There is real value in having consistently numbered rows, but without some sort of renumbering, inserting a row into an existing numbered table of can be a real pain. For example, when creating a list of requirements, I need to add new entries and move items around. I then want the numbering to adjust accordingly.

In some documents, I need to build several lists, so I need the ability to add a prefix to the numbering in each table, so that across the document as a whole, each entry is unique.

Sometimes I need to reliably lock down the numbering in a given table so that new entries don’t automatically change those that already exist. I can then safely renumber the new rows manually.

Appearances matter too, at times I need to use different numbering styles, from the simple (1,2,3,…) to more complex formats such as (A.1, A.2, A.3,…) or (NF-01, NF-02,NF-03…) that involve different sections within a given table, and using different separators, with or without leading zeros.

Word does offer some basic tools for this kind of formatting. For example, it allows you to use outline numbered lists in the first column of a table. I have found these to be tricky to use, especially with prefixes, and it is hard to lock down the numbering at a certain point, so you can be sure that nothing changes.

To address these issues, I decided to write my own one-touch renumbering process.

Inserting and Deleting Improvements

One of my key requirements is the ability to quickly add new rows. I often need to record several new ideas in a table very quickly, for example, when recording workshop findings during rapid discussion.

Word lets you insert lines, but this can require several keystrokes, and you have to be careful how you do it. In Word, it matters whether you insert above or below the current line. I would often get it wrong, and end up with section or heading row formatting copied into the body of the table, and have to use even more keystrokes to correct this.

I decided I needed a one-touch insert function that reliably inserted (say) 5 blank lines below the current line and positioned the cursor ready for rapid entry.

Creating blank lines for quick entry means occasional empty, unused lines. I decided I needed a table clean-up routine to remove unwanted rows before the renumbering started.

Having a one-touch insert function suggested the need for a complementary one-touch delete, something that would delete rows if rows were selected, or regular text if that was selected instead.

Getting Started with the Build.

Microsoft Office comes with a development tool called VBA. You can get started with VBA by having Word record a series of keystrokes and then see how these actions have been converted into VBA code ready for repetitive use. There is a vast amount of information on the web about getting started with VBA, and most BAs will be productive in just an hour or two.

I decided that my table tools would be launched by shortcut keys rather than by using the Ribbon menu. Ribbon coding isn’t for the faint-hearted, and for speed reasons I wanted to keep my fingers on the keyboard as much as possible.

I needed a way of making the tools available to any document without having to load code into each. I found that Word allows you to load a template into its startup folder. This gets opened automatically and allows the code within it to be used by any document. In some environments, this code needs to be digitally signed, but there are simple tools available to self-sign the code for each PC you use.

My first major task was to prove the tools could be invoked correctly. I did this by creating some test routines, assigning them to shortcut keys and confirming I could use them whenever a I needed.

I then tested the basic table manipulation tools in VBA. These included stepping through each row, updating text, deleting rows and similar functions. Word has some quirky ways of marking the end of text in cells, so these tools took a bit of getting used to.

I also needed to store information about the tables. For example, which tables allow renumbering, whether a prefix being used, and what separator should applied. To do this, I decided to use custom document properties, and had to build a set of tools to read these values and update them when they were changed by the user.

The basic routines came together fairly quickly, but I did spend quite a while making the logic handle the wide variety of table manipulation tasks that a BA needs.

I also found that my use of tables really took off when I simplified the text styles I used for tables. I recommend taking the time to set up new styles for standard table text, table bullet points and table headers. Keeping these separate from the regular text styles allows easy change of the fonts to fit the changing cell space availability, and assigning these styles to shortcut keys means they can be used quickly and reliably.

Don’t forget to leave your comments below.