If you are pulling your hair out with your organization, keep reading!
In this tidbit I will share some stories of how we have helped companies with the various challenges they faced. Pick out a lesson from one of the stories and try something different to improve your results!
There are five short stories and lessons:
- Getting developers and testers to work together on testable requirements
- Moving to Scrum wisely and fixing existing Scrum implementations
- Fixing project planning and prediction
- Fixing team work
- Adopting and combining best practices in the way you want
1. Getting developers and testers to work together on testable requirements
When you hear a tester say, “What is the code supposed to do?” “How am I supposed to test that?” then you are seeing a huge amount of wasted time as they go back and forth trying to determine how to proceed.
For example, the developer writes code to sort a series of numbers. The requirement (written by the developer) and code module are both called “jeffs-recursive-special-array-sorter-latest.” After writing the code, he hands it to the tester. The tester has no idea what is being sorted, why it is special or what recursion is. Two weeks later they eventually pin it down.
You might laugh, but I have been brought into many organizations by testers who ask me how they should test such requirements. I ask, “Where do you see requirements?”
In these situations we teach developers and Business Analysts (Product Owners) to work together when writing requirements. The resulting requirements meet a user need and contain the details that testers can test against, i.e., a testable requirement. The collaboration eliminates wasted time.
The lesson: Have developers and testers write testable requirements together to quickly identify ambiguities.
Related articles: http://processgroup.com/software-requirements/
2. Moving to Scrum wisely and fixing existing Scrum implementations
It has become an obsession to adopt Scrum or become Agile. There, I said it!
However, using Scrum/Agile is not problem-free. Two common issues that organizations experience are ditching everything in the past that actually worked, and sliding down the slippery slope of, “We don’t have to do that, now we are Agile.” If you repeat these two approaches long enough, little remains. Hence the problems.
When teams are already doing Agile/Scrum and become totally disenchanted, it is usually because basic practices that they used to do have been forgotten about. The assumption was that Agile would take care of everything, so why perform practices from the past! Examples of the current state include: no release planning, reliance on mumbo-jumbo user stories, (“As a developer I would like to write my new interface code by Tuesday”), no version control of anything, and no end-to-end user-focused system testing.
When helping teams adopt Agile/Scrum, we make sure that the intended benefits are obtained — early and frequent user feedback, reacting to change, visible work — along with integrating existing good practices into Agile/Scrum so that old problems don’t reappear. Sometimes this means reminding good PMs of a few things they used to do but stopped because they were told, “Hey, Agile will take care of that.”
The lesson: Agile/Scrum is a framework, not a complete system. What practices did you ditch and what problems is that causing?
Related articles: http://processgroup.com/agilescrum/
3. Fixing project planning and prediction
In the old days (circa 2008), project managers (PMs) used to do robust estimation with their team members, assess risk, identify dependencies, negotiate scope and manage all of the stakeholders with their wild needs and opinions. The PMs that still do this today deliver within predictable budgets and deadlines.
The new wave of PMs take the deadline as the estimate and run as fast as they can, knocking over people, stakeholders, budgets and profit needs. It’s not pretty, as you might know.
In these situations we help PMs learn and refine their skills to address the challenges they face. This usually involves working with senior management to help them understand what PMs are doing, the issues they face, and how to support them in the sticky projects they have.
The lesson: PMs need lots of skills to manage project complexities. Do a quick skill-inventory check on your PMs. Our PMs:
- Develop clear goals based on customer needs
- Develop a robust and organized task list
- Perform estimation with at least two methods for contrast
- Assess and manage risk with team input and share with management
- Identify stakeholders, dependencies and the Critical Path
- Negotiate achievable deadlines and options with known risk
- Track and communicate progress routinely with team members and stakeholders
- Take corrective action as soon as needed with no wishful “I am sure it will get better.”
Related articles: http://processgroup.com/project-planning-and-management/
4. Fixing team work
Everyone has problems. It is the sign of life; don’t panic. However, when team problems are not resolved, teamwork fades since teamwork includes the ability to bring up and resolve sticky issues. When issues are not resolved, negative communication is taken as a personal attack: “He said ABC because he doesn’t like me.”
We help teams by being the go-between until they are self-sufficient. For example, we listen to Jane (who does not like Amit), and then convey what she said to Amit in a way that meets his goals. Then we take what he said and translate that back into something that meets Jane’s goals.
This goes on for a little while, after which we point out to Jane and Amit what we are doing. Then we have them try the same style until they become self-sufficient.
When there are super-sticky issues to resolve, we point them out and get the team over the hump. Since we can’t be fired, we diplomatically and objectively raise issues that others are afraid of.
The lesson: Team work happens when sticky issues are resolved quickly.
5. Adopting and combining best practices in the way you want
When an organization gets tired of experiencing pain, the leaders realize that they are not using many of the best practices available. We help people determine what they are doing well (so they don’t break it), diagnose what is causing their pain, and integrate new practices into the existing work flow.
Some organizations decide that they don’t want to reinvent the wheel, so they adopt frameworks such as CMMI and PMBOK*, where many others have done the leg work to enumerate and organize useful practices. The challenge is then how to implement these practices quickly, with the right amount of process, in the work flow you actually want to follow.
Most organizations treat frameworks such as CMMI and PMBOK as obstacles that have to be overcome to get to the coding phase. No best-practice integration, no refinement, just an obstacle and an obstacle mindset.
To help organizations through this, we provide mappings of the common published frameworks and guide teams through adopting new practices, making sure they fix existing problems while running a project. We also help them put all of the process stuff into short checklists and have them use their existing workflow tools (e.g., JIRA, SharePoint, RallyDev, TFS etc). The goal is more performance from process, not some performance then process.
The lesson: If you align existing needs with new practices, make implementation light-weight, and focus on the appropriate sequence, you can repeatedly kill three or four birds with one stone.
Related articles: http://processgroup.com/improvement-planning-cmmi-and-appraisals/
If an idea resonates, pick one action and try it. If you, or your big boss, would like help on the multitude of issues we cover, contact us for a complimentary 45-minute chat, or just send an email.[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link
*CMMI: Capability Maturity Model Integration. PMBOK: Project Management Book of Knowledge.