Requirements have gone from lengthy specifications that state “The system shall…” for dozens of pages, ad nauseam, to a single sentence story. But stories aren’t meant to capture all the details needed to build a feature, so where do those details come from? Continue reading “Use Examples”
Many teams and organizations try to create one-quarter roadmaps. Here are the problems I see:
- Teams spend a ton of time estimating what they might do and then they select what will fit into a quarter. They feel or are asked to commit to all that work.
- The product managers and project portfolio managers depend on the team finishing everything the team commits to. Too often, they use the team’s commitments to create external dates.
In 1965, Ralph Nader became a household name with the publication of “Unsafe at Any Speed”, his pointed critique of the serious safety risks foisted upon consumers by the American automotive industry at the time. The oligarchs, ahem, leaders of this industry remained complacent with the delivery of their killing machines, emboldened further by an inept, if not corrupt, Federal Trade Commission. Companies were not held to account for their safety records, all of which were problematic. Because of this widespread lack of accountability, safety was not seen as a competitive advantage. And without fear of corporate downside, investments to address these risks were neither seen as prudent nor as a competitive advantage. Such is the state of some key aspects of application security today. Continue reading “Insecure at Any Speed”
A few weeks ago we looked at the Definition of Done, which describes the conditions which must be satisfied before a team’s deliverables can be considered fit for release. That’s the acid test of what “Done” ought to mean.
Can a team’s output actually be deployed into production and used immediately, or is any work still outstanding?
We saw that a team’s Definition of Done will often fall short of this essential standard, and “technical debt” will be incurred as a result. This debt reflects the fact that certain things still need doing, no matter how small or trivial they might be held to be. Additional work will need to be carried out before the increment under development is truly usable. Perhaps there might be further tweaks to be done, or optimizations, or tests, or integration work with the wider product. Any such technical debt will need to be tracked, managed, and “paid off” by completing the outstanding work so the increment is finally brought up to snuff. Continue reading “Walking Through a Definition of Ready”
Google studied 180 teams through its Project Aristotle over two years. They were on a quest to find the common traits among the most successful ones. Going in, they assumed the best teams were comprised of the most skilled people. But that wasn’t the case. Instead, they found 5 core characteristics of high-performing teams:
- Structure and Clarity
- Psychological Safety
How can we incorporate these important characteristics into your team? Continue reading “Google Says These 5 Characteristics Can Make or Break a Successful Team”
Most of you probably have some tried-and-true best practices that you lean on to formulate requirements and articulate what needs to be done.
In many cases, that may involve the creation of use cases and user stories. While both are valuable tools, neither go quite far enough in defining the problem and desired outcome. But as I think you’ll see, a very simple change in the user story format will profoundly impact the finished product. Continue reading “How to Write Smarter User Stories for Product Design and Development”
Getting software updates to users quickly is paramount in today’s world. You know from your own phone, mobile, and computer usage that software updates for applications are a daily occurrence. We live in “internet time.” The ability to be quick and responsive with value to meet users’ needs can mean great success for a company, but the inability to do so could mean the death dive.
In order to survive in this world, you must be able to produce both swiftly and frequently. This is how you get ideas out fast and bring business value to customers. And, being able to do this requires agility. Working in the traditional Waterfall process of software delivery where there was a long drawn-out series of investigation, analysis, and planning doesn’t cut it anymore. Agile development allows you the framework that is critical to optimize planning, testing, and implementation. Agile development is a way to have faster cycle times, the goal being to achieve “internet time.”
Achieving Continuous Delivery and Continuous Deployment in the Solution Delivery Pipeline means your organization is nimble and can release updates to users in a responsive manner; these 2 phases in the pipeline are very important to the overall goal of fast, responsive deployments. However, sometimes there is confusion about what they are. In this article, we clarify the difference between Continuous Delivery and Continuous Deployment and describe how each fits into an Agile environment. Continue reading “Continuous Delivery vs. Continuous Deployment: An Overview”
Whether we’re limiting the times we hit the snooze button, increasing our attendance at the gym or improving our work performance, setting goals is essential in order to generate change. Yet, goals don’t always work: According to Statistic Brain Research Institute, a mere 9.2 percent of participants the institute surveyed said they’d successfully achieved their New Year’s resolutions so far in 2017. Continue reading “How to Set Goals That Will Turn an Average Team Into All-Stars”
Whilst the Scaled Agile Framework (SAFe) has evolved significantly over the years since inception, one area that has lagged is that of metrics. Since the Agile Release Train (ART) is the key value-producing vehicle in SAFe, I have a particular interest in Program Metrics – especially those produced on the PI boundaries. Continue reading “Revamping SAFe’s Program Level PI Metrics Part 1/6 – Overview”
While the DevOps movement and associated technologies have garnered much attention and fanfare, few have addressed the core issue—the handoff from development to operations. This blog post explains why release management is the bridge between development and operations, and how you can strengthen that bridge with the right approach, tools, teams, and processes. Continue reading “You Can’t Have a True DevOps Culture Without Effective Release Management”
How can you tell if you would benefit from having technical skills as a product owner? To answer this question, I find it helpful to look at how the role is applied. If you manage a digital product that end users employ, such as a web or mobile app, then you usually do not require in-depth technical skills, such as, being able to program in Java, write SQL code, or know which machine learning frameworks there are and if, say, TensorFlow is the right choice for your product. Continue reading “Do Product Owners Need Technical Skills?”
There’s a noticeable shift toward agile development taking place within the federal government. Driven by a need for accelerated application development and meeting internal customers’ needs on the very first attempt, agencies like the General Services Administration and Department of Homeland Security have begun to move away from traditional waterfall project management frameworks and toward iterative, agile frameworks like scrum. Continue reading “4 steps to agile success”
￼More development teams have adopted agile and lean ways of working to deliver better quality products faster. Despite their efforts, they’re still missing deadlines and churning out buggy software. Most of these teams are expected to solve business problems, but their work doesn’t align with business objectives. In fact, there’s a huge disconnect between development teams and the organizations they serve. Continue reading “Agile Can’t Succeed as an Island”
Sing it with me… “As a _user_ I want to _perform an action_ so I can _achieve an end result_.” This is great in theory, but writing good user stories is harder than it sounds. I’ve seen well-meaning product, design, and engineering folks take this approach to user stories and interpret them as magic words. Somehow, as long as we begin our task statement by uttering the “as a user” mantra, we’re magically taking a user-centered approach. Continue reading ““As a User” Needs to Stop”
￼After careful review of her harried work life, Charla, an IT manager, discovered that 20% of her time over the previous two months was spent managing escalations. It seemed that each interaction with her team ended with her feeling a need to exercise her authority to rescue them from a crisis. Continue reading “When to Solve Your Team’s Problems, and When to Let Them Sort It Out”
There is a well-known story about a cleaner at NASA who, when asked by JFK what his job was, responded “I’m helping to put a man on the moon.” This anecdote is often used to show how even the most mundane job can be seen as meaningful with the right mindset and under a good leadership. Continue reading “How to Make Work More Meaningful for Your Team”
Mistruths promoting the cure-all, Agile and DevOps, hurt everyone seeking a truly better way to deliver software. ING begun its agile transformation in 2010 with just three teams practicing agile. After seeing the success of those first three teams, ING transformed its entire development organization to Agile in 2011. While the transformation was deemed a success, ING found it wasn’t making much difference to the business, so it began forming its first DevOps teams. By 2014 ING executives felt that they weren’t receiving the benefits from Agile and DevOps for which they had hoped. Continue reading “Agile and DevOps are failing in Fortune 500 companies. It should be a wake-up call to all of us.”
Planning Poker relies on relative estimating, in which the item being estimated is compared to one or more previously estimated items. It is the ratio between items that is important. An item estimated as 10 units of work (generally, story points) is estimated to take twice as long to complete as an item estimated as five units of work. Continue reading “The Best Way to Establish a Baseline when Playing Planning Poker”
Agile promises rapidly evolving software and substantial business benefits, but it requires new habits from everyone: from IT and from business partners.
Agile development has largely become synonymous with digitization: senior business leaders have realized that their companies cannot take full advantage of digital tools and technologies without having new, amped-up processes for managing them. The value of these processes is immense. Continue reading “A Business Leader’s Guide to Agile”
Last summer, I changed companies. I had changed jobs before, but this time was different. Not only was I leaving a life of knowing everything (well, almost everything), but I also was leaving a product (LISA) I had invested the past 10 years of my life in supporting (like breaking up with a longtime girlfriend). Little did I realize then that I was about to start my Agile journey all over again. As a product manager, this journey was to take developers who were implementing cowboy methodologies to Agile Scrum. Along the way, we moved from JIRA and Grasshopper to IBM Rational and then to Rally (CA Agile Central) and managed not to lose all the stories and to keep some history of stories to source control for supported versions. The learning and the journey were amazing; there’s nothing like supporting a test product that drives Agile transformation but also helps your own development team adopt and understand Agile transformation. Continue reading “The SAFe Bet Over Agile Scrum for Enterprise Applications”