Tag: Assessment

Speaker Spotlight! Business Analysts – Do We Need Them?

Written by David Barrett on October 20, 2015. Posted in Articles.

Come hear David at Project Summit BA World Boston on October 27 delivering his keynote presentation “What’s In Your Communications Engine?”

I originally wrote this post in 2010 as I sat on a flight from Sydney to Wellington, New Zealand. I was there running a Business Analyst conference in each city. Here is what I wrote at the time…

These folks, (business analysts) are really struggling: for recognition, for job security, for a well defined career path and for a recognized set of defined core competencies. Most of their organizations are just now figuring out what a BA is, and can do, but unfortunately the recognition is limited to a few departments or individuals.

Most of their peers have not got a clue as to what they do.

If you are project manager working on construction, engineering or any other large capital project – ignore this plea. You have your architects, you appreciate them and you support them. Thank you.

But all other PMs reading this – it is time you woke up and realized how valuable a BA can be to you. If you want good, solid, detailed specs for your project – find a BA. If you want to work on a project that has complete customer sign-off before you even get on the scene – find a BA. If you want to walk into an environment that has all stakeholders identified and consulted with – find a BA. If you want a ‘partner’ on your project that will help you when anything changes in mid-stream – find a BA!

Business Analysts are out there and every IT and non-IT business project needs one. Not all projects will get one – but they need one. BAs are being educated, they have conferences to go to, they have their own association (IIBA) to belong to, a body of knowledge and a professional certification programs to aspire to.

For years you have been complaining about incomplete customer specifications, weak links to the stakeholders and no blueprints whatsoever. This is why we need business analysts! They are called Business Analysts (BA), Business Systems Analysts (BSA), Requirements Managers, Systems Analysts and many, many more titles – but they all mean roughly the same thing. They will help you build the right thing the first time. And so now in 2015 I re-post… Some organizations understand this. Others hear it but have still not taken up the challenge. Others are still in the dark.

Where are you on this?

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!

Leadership Lessons: Poor Managers Thwart Good Organizations

Written by Peter de Jager on August 27, 2015. Posted in Articles.

Over my career, I enjoyed full-time employment with eight different organizations, and with the exception of the last one, in each case I joined a good organization and then ultimately quit a poor manager. The last one is the notable exception because that’s when I quit to start my own organization and no manager, good, great or brilliant could have kept me on the payroll.

Over the years, as I’ve listened to friends and associates relate their work experiences and soaked up a myriad of stories from the workplace, I’ve come to the conclusion that my “joining and quitting” behaviour wasn’t that unusual. We join organizations and we quit managers. This isn’t an idle observation; it’s an incredibly costly one. How much of our turnover is due, not to official management philosophy, but instead to either ignorance of that philosophy or simply due to a single manager’s inability to manage?

If we take the time to carefully examine how people become managers, this isn’t that surprising. We promote ‘doers’ to supervisory positions and rarely make any effort to train them how to ‘supervise’ rather than just ‘do’. Perhaps more to the point, when we first become managers, we’re typically oblivious to the fact that ‘management’ is a fundamentally different task compared to anything we’ve done in the past. This can lead to incidents worthy of the most amusing TV sitcoms.

Many many moons ago, (yikes… about 325 moons ago to be precise) I was promoted from an analyst position to a supervisory role, for the next 2-3 years I stumbled along the rocky road to management, inflicting pain and anguish on myself, my staff and my clients. Why? Because I really had no clue what it meant to be a ‘manager’ of people.

As a manager, my department was responsible for an awful lot of work. Even though I had six people reporting to me, I operated under my old belief that “if you want something done right, you have to do it yourself”. Have you ever seen someone trying to do the work of six people? People would see me barreling down the corridors of the organization and dive out of the way, for fear of being run over. The “do it myself” philosophy is a successful strategy for a hands-on problem solver, but for a manager? It was a disaster. A manager must learn to delegate, and it’s not something that’s intuitive.

By doing the work myself, I was communicating very strongly that I didn’t value my staff – people quit managers for that reason.

Once I grasped I had to rely on other people, I started to give them assignments, but I didn’t trust them. It was my department, I was responsible for getting the work done correctly, so I micromanaged them. This is a euphemism for what I really did. I perched on their shoulders looking at their work. I constantly kibitzed. I reached for the keyboard. I interrupted. I intruded. All with the best of intentions. What it took me a long time to learn on my own, was that what a good manager must do, is give up control, in order to allow their people to work. Yes, as a manager I was responsible for the work, but that did not mean I had to have full control from minute to minute. As a worker that makes no sense, as a manager it’s our new reality.

By micromanaging I was communicating very clearly that I didn’t trust my staff – people quit managers for that reason.

Even with the rudiments of delegating under my belt – I was a very busy person. There was lots for a manager to do. People to see, reports to write, information to gather etc. etc. That didn’t leave much time for inconsequential meetings with my staff and certainly no time for one on one meetings. I prioritized what I thought was the important stuff, and left no time for my staff. I was a manager in absentia. I didn’t realize that until I made the time to know more about my people, that I’d never be able to create a team, instill loyalty or give my ‘human resources’ a sense of purpose.

By not making time for my staff I was communicating very loudly that I wasn’t interested in their well-being and growth – people quit managers for that reason.

Those are just three mistakes made by a somewhat reasonably intelligent person thrust into a management role without training. There were other mistakes I made, and some that I intuitively avoided. I never chastised an employee in front of others – but I’ve seen new (and sadly older) managers do that. I never broke a promise to an employee, but I did inadvertently play favourites. I gave the most interest assignments to the most capable – without realizing that that created resentment amongst other staff members – and without realizing that interesting assignments are the best training tools at my disposal and the very best way to motivate people to excel and to build loyalty.

It requires no mean intent to be a bad manager; all that’s required is ready made ignorance. The cure is a minimal continual dose of management training provided before, during and after the transition to managing people. People quit bad managers. Regardless of how good the organization, no matter the public image, it’s the person we report to who has the greatest contribution on our daily work experience. Bad managers drive out good employees.

By the same token, a good manager, one who treats their employees fairly, honestly and with integrity will retain staff in all but the most tyrannical of organizations. Even though Gandhi wasn’t a traditional manager he had it right, “Be the change you want to see in your organization” – even if his ‘organization’ was the entire world. His wisdom still rings true, for better or worse it is individuals who create the world/organizations we live in.

Leadership Lessons – When Were you Last Engaged?

Written by Peter de Jager on July 31, 2015. Posted in Articles.

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)

You Can’t Have Your Agile Cake and Eat it Too!

Written by David Shaffer on July 31, 2015. Posted in Articles. 1 Comment on You Can’t Have Your Agile Cake and Eat it Too!

It’s probably safe to say that many organizations that perform software development are either using some form of Agile methodology or are in the process of implementing Agile. Management in these organizations very likely believes that Agile will deliver numerous benefits to the organization thereby allowing them to receive numerous accolades, applause, and recognition for their incredible foresight. Unfortunately, these lofty expectations are often wildly out of line and potentially detrimental to their organization. Frustration and disappointment are the typical reality in organizations adopting Agile for the first time. Understanding the root causes of this frustration will help avoid disappointment and the disruption to productivity in your project teams.

In my experience, the number one cause of team frustration and disappointment experienced by large development groups moving from a command and control Waterfall structure to Agile has been executive management’s need to feel as if they are contributing to a project by deciding priorities and dictating deadlines.

The Agile Manifesto simply states that software development teams should place more value on individuals, team interactions, working software, customer collaboration, and responding to change. In contrast, Waterfall places value on heavyweight processes, tools, plans, and documentation. Organizations looking to move to a more Agile methodology have typically been managed as command and control Waterfall shops. The command and control management style consists of executive management deciding on project priorities and then dictating deadlines. Project Management then creates a work breakdown structure or some other tool to identify all the tasks required for project completion and the Waterfall begins! Management’s comfort level with this command and control style is a major source of friction within an Agile methodology. Let’s face it, executives don’t complete any of the direct work related to a project. They don’t write requirements, write code or test the product. Therefore, the only way they feel they can contribute to a project is to use the big stick associated with the command and control style of dictating a deadline and forcing the team to perform heroics to meet it.

Software development teams are well aware of the Agile Manifesto and what it promises. They are generally excited about the opportunity to work in a more Agile environment and be freed from the confining command and control mindset. When our department embarked on the journey to convert from a very strict Waterfall methodology to Agile, there was tremendous hope, excitement, and enthusiasm. Teams were very anxious to move away from our current process which literally dictated that development could not begin until every requirement was officially approved by management. Obviously this was an ineffective and unfulfilling way to develop software since the inevitable requirement changes that were discovered could not be implemented without going through the entire requirement review and approval process. Projects were routinely late, over budget and failed to fully satisfy the needs of the business. After a few years of this inept performance there was a complete reorganization of the top levels of management and a mandate that our department look to Agile to save the day. Once the new management was in place, the Agile consultants began to appear. These consultants began coaching the organization on the techniques associated with Agile. Terms such as “Standup”, “Iterations”, “Retrospectives”, “Backlog Grooming” and “Iteration Planning” spread through the organization like wildfire. In hindsight, I could have made quite a fortune running a buzzword bingo game back then! Optimism was high and new objectives for learning and implementing Agile littered everyone’s yearly performance objectives.

The initial rollout of Agile went relatively well on a small proof of concept project. Based on these results the management team approved the use of the new Agile methodology on the complete redevelopment of our flagship product. This was to be an eighteen-month effort. The first misstep in our rollout of Agile was the demand that the Business Analysis group identify all of the Use Cases associated with this effort up front so we can estimate the entire project and calculate a deadline. Old habits die hard and it’s tough to teach an old dog new tricks would be appropriate cliché’s to describe this situation. The BA group pushed back against the idea that all Use Cases could be identified up front and stated that we thought we were going to be Agile. Nonetheless, we were forced to provide our best guess and the Project Management group came up with a hard deadline 18 months away. The team was now committed to delivering a complete rewrite of a product that was in production and being modified for seven years in a span of eighteen months! It’s ironic that our first step in the new Agile world was to complete a typical command and control task of identifying all work up front and spitting out a deadline. The team expressed the discomfort with this deadline but was assured by management that everyone understood this was a target and not a commitment. In reality, whenever a date is communicated to upper management, it becomes the expectation for delivery no matter how many times it is said to be only an estimate.
The team began development utilizing all of the shiny new Agile tools the consultants taught the group. Standups were attended and the textbook questions of “What did you do yesterday?”, “What will you do today?” and “Do you have any roadblocks?” were asked and answered. It became apparent pretty quickly that these questions were not very helpful. The team asked if we could abandon that script and simply use the time to communicate directly without the constraints of the three textbook questions. Project Management’s initial response to this request was negative. We have to follow the Agile methodology which says we must ask these three questions during a standup!
This is the second major cause of friction and frustration with an Agile rollout. Project Management begins emphasizing the Agile tools and processes over team collaboration and interpersonal interaction.

Ironically this is a completely anti-Agile approach. Over time, we were successful in convincing Project Management that the team should be empowered to decide on the structure and frequency of standup meetings. Unfortunately, this was quite a battle and caused a fair amount of friction between the development group and the PMs. It’s fair to say that the bloom was off the rose and the initial excitement and optimism associated with the Agile rollout was starting to wane.
This was the first of many battles between the development team and Project Management over the use of the Agile tools. The development team was forced to provide initial point estimates for each Use Case and Change Request that was accepted into each iteration. The Project Management team then used these point totals to calculate team velocity. Team velocity was then used to compare the supposed productivity of each team. Management was informed each week how many points each team was able to accomplish, “Team 1 completed 80 points this iteration while Team 2 completed 40 points!” This inevitably led to the question from management as to why Team 2 was half as efficient as Team 1. This is yet another source of friction and frustration with an Agile rollout. Point estimations used in calculating team velocity is simply an Agile tool which may help predict approximately when a feature may be completed by the development team. However, since old command and control habits are hard to break this tool is easy to use as a way to question the effort of a development team. Questioning effort based on an initial estimate that was provided without knowing all of the complexities related to the work leads to low morale and further disillusionment with the Agile method.

The team dutifully soldiered on with development and attended the structured Agile meetings. Standups, Iteration Planning, Backlog Grooming, Retrospectives, and Showcases were all scheduled to occur each iteration and were well attended. However, as time went on the usefulness of holding a retrospective at the end of each iteration began to wane and was questioned. Over many iterations continually answering “What worked?”, “What did not work?” and “What should we improve?” devolved into repeating the same things over and over. Additionally, holding mandatory showcases at the end of each iteration was also proved to be more of a negative than a positive experience. Each iteration did not necessarily deliver a full set of functionality for a feature, so showcasing the team’s work like clockwork caused confusion with the stakeholders. In light of these discoveries, the team pushed back against Project Management to see if the frequency of these mandatory Agile meetings could be adjusted. Similar to previous requests this was met with resistance. The PM’s argued “Agile says we must have a retrospective and showcase at the end of each iteration!” Once again the command and control mindset of dictating heavy process to the development team was rearing its ugly head. Morale on the development team sank once again and further disillusionment with the idea that we were Agile continued.
As we marched towards the non-negotiable deadline set many months ago, it became apparent that we would struggle to complete all of the work included within the Minimally Viable Solution (MVS). Business stakeholders began to realize (or started paying attention to) what was actually included in the MVS release of the product and began demanding additional features. Management bowed to this pressure and asked the teams to squeeze in as many additional requests as possible before the deadline. The development teams heroically worked 60+-hour weeks and delayed summer vacations in the final iterations to deliver the product at the deadline. This effort further skewed the team velocity reports since it showed the teams completing 100+ points per iteration. Some in management inevitably asked why they were so productive late in the project or commented how a fixed, non-negotiable deadline drives project completion. In reality, this experience further soured the development teams on our new “Agile” process since it certainly felt like the old “command and control meet the deadline or else” Waterfall process.

At the completion of the project the development teams, project management, and executive management began working towards a more agreeable Agile methodology that would be more in line with the actual Agile Manifesto. The keys to developing an Agile methodology that actually delivers the promises of greater efficiency are the following:
1). Recognize management’s comfort level with a command and control management style which dictates process and deadlines.
2). Recognize Project Management’s comfort level with dictating process and resisting team empowerment

The key to overcoming these realities is to develop trust between self-empowered development teams, project management, and executive management. Executive management must clearly define each role’s responsibility and authority within the project to ensure the teams are truly empowered to choose how they will utilize the Agile toolset. Once these roles and responsibilities are clearly understood, the development teams must earn the trust of management by consistently delivering working software while using the Agile tools. It takes time to establish trust. Allowing self-empowered teams to utilize the Agile tools according to their needs removes the friction associated with combining a command and control mindset with Agile.

I will provide a framework for communicating team responsibilities and authority levels to ensure Agile success in a future article.