The Product Owner role is implemented in organizations in various different ways. The responsibilities and authorities of Product Owners vary across organizations, departments, teams, and Product Owners. This can be explained to some extent, because it is a role that people need to grow into. The role requires some specific competencies and a specific mindset. In addition, for many organizations, it is a new and unknown role in which people (typically management) are trying to find the right balance of responsibilities and mandate. Preferably, a Product Owner has a lot of mandate and he or she is the final decision maker for the product. In many organizations, this is not (yet) the case, however.
In order to create clarity about the level of Product Ownership in your organization, we distinguish five types of Product Owners:
Achieving predictability of quality is very important for successful software releases. Achieving a high quality of projects/products is the ultimate goal for everyone. To ensure projects are delivered with the highest quality, it is important to follow Engineering Best Practices (EBP). These EBP’s will be the custodians of quality, they will drive the process to ultimately achieve the quality.
To achieve the code quality that will turn into overall quality, it is important that the code goes through the below processes regularly.
I’ve heard “The end is near!” for business analysts for almost 20 years. Waterfall project management, with its need for formal requirements, is dead, a dinosaur, so 1990’s. To be honest, that’s mostly true. With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-thick formal requirements document. I’ve written them, and to be honest, I don’t miss them. Agile espoused iterative, rapid development and quick delivery of functionality, whether it be big or small, allowing a project team to, well, be agile. Direction, goals, deliverables and requirements could be adjusted, redirected or scrapped altogether every few weeks. “Wait a minute Mike, I just heard you say the ‘R’ word in…‘Requirements’”. Yes, I did, and it wasn’t a mistake. With very few exceptions, every project needs requirements. You need to know what the project is supposed to deliver, why there is a team and a budget, and why the project has some catchy name (typically in the form of a questionable acronym).
Here how it’s supposed to work (feel free to skip ahead if this isn’t your first Agile Rodeo): In a fully adopted Agile1 project, the customer (aka the “business”) is a part of the team. They speak directly to the developers and describe what they want the solution to do. The business and the developers go back and forth discussing, defining and refining, until the developer has a pretty good idea what to build. The developer runs off and writes code, tests it and demonstrates it to the business at the end of the Sprint2. The team (including the customer) reviews what was built and demonstrated, and correct or redirect the next round of work. Lather, rinse, repeat.
Throughout this series of articles I’ve explored how we need to bring the same rigor to architecting our software delivery value streams as what we’re witnessing in advanced manufacturing plants. Once we agree on what flows, we can analyze those flows to identify bottlenecks and opportunities to remove them. However, every time I’ve asked an executive-level IT leader where his or her bottleneck is, I’ve received either a blank stare or a vague answer, from otherwise extremely capable people.
To look for a bottleneck in a production system, we must first understand what flows through that system. We’ve seen many measures of software delivery flow proposed and analyzed, including lines of code (LOC), function points, work items, story points, deployments, and releases. Each captures a notion of value flow from a different perspective, but each has its limitations, especially when you consider the end-to-end flow of business value through a delivery pipeline. If my experience talking to IT leaders is a guide, from a business perspective, we simply don’t have enough consensus on this core question of what flows through a software value stream. Yet this should be the most fundamental question to answer if we are to apply lean principles to software delivery.
It’s rare to find a business today that doesn’t rely on digital technologies and services. Retail is one example: whether customers are buying online or in store, completing a transaction requires a website or point-of-sale system. The entire supply chain relies on IT services to deliver goods on time, to the right locations, and just like any company today, every department — from development and marketing, to HR and business services — has a critical tech stack.
This increasing reliance on technology as the engine of the business, coupled with user expectations of having always-available services, means technology disruptions or degradations have an immediate impact on customers. It also means that the ability to respond and resolve issues in real time is more important than ever. And while some organizations are set up to handle real-time work, most companies are not: they lack the technology to support real-time work, their processes are designed around queued work, and their employees called upon to do this work are not enabled with the necessary knowledge or empowered to perform it.
It’s incredible to think where we’ve come in the last 30 years. We’ve digitized much of our daily lives, including our interactions with each other and the tangible world.
As such, we’ve had to evolve and adapt how we consume technology: touch, voice, sound…taste? We’re having to transact increasingly complex information with more things with less time. It truly is chaos! Or at least it would be if we didn’t apply gestalt psychology to our interactive experiences.
I have a hard time saying "no" to people at work. They’re super passionate about their projects and the passion is contagious. Plus, I want to be helpful. As a result, my calendar eventually gets so packed with meetings that the mere act of looking at it makes me feel overwhelmed AF.
The worst are the "zombie meetings" – the ones that no longer do anything other than destroy your productivity but continue to live because nobody has figured out how to kill them. (There’s a good chance any "weekly syncs" on your calendar are zombie meetings.)
[Recently Elon Musk (Tesla CEO) talked about taking his company private. Read how a Zone Leader recalls a situation where a publicly traded company considered going private in an effort to avoid SOx compliance.]
In early August, Tesla CEO Elon Musk indicated he had secured the financial means to take his company from a public traded company to a private corporation. This was around the stock price had plummeted from just under $371 a share down to right above $290 a share a week earlier. Certainly, the memories of the yearly low price of $252.48 were still on his mind as well — not to mention some unfavorable press releases regarding their underlying technology.
The book Agile IT Organization Design – for Digital Transformation and Continuous Delivery by Sriram Narayan explains software development as a design process. The following statement from the book means a lot.
"Software development is a design process, and the production environment is the factory where product takes place. IT Ops work to keep the factory running.."
It questions the way we traditionally think of operation support, maintenance, production bugs, rework, their costs and budgets and the focus in software development life.
Ask any developer to estimate how long it will take for them to finish a project. You will see the loathing in their eyes. And for good reason. Estimates have been wrongly used for decades by a lot of managers who then hold the team accountable to their estimate as if it were the actual deadline. Even more frustrating, in many cases, those managers only act on the lowest number they hear from you! It’s as if they had a min() function, and they just keep trying to get the number lower. But engineering is not magic!! No wonder the hashtag #NoEstimates has become famous.
For this to happen, we (well…especially managers) need to abide by a few rules. Then we’ll see how estimates can improve the quality of your software. Yup, you read that right. Well, in my opinion, obviously.
Selecting the right foundation for your business is essential to long-term success in a very competitive environment. However, quicker delivery to market can give you a very profitable head start over the rest of the competition. The major question that pops up at that very moment is which among the two should be prioritized. The answer to such a complicated question becomes less complicated as you place both business decisions on the table for a complete comparison.
A good foundation for an application can be defined as one where each layer and feature of the application is hard-coded, where the developer has control over the application and has the option to improvise according to the demands of the customer. Therefore, the most important question when it comes to developing an application is, “Will the application owner have complete control to make customizations to the existing application at each level of the development cycle?”
One question that I hear a lot of people asking is whether they should buy or build the software that they need to run their enterprise. This is often a difficult question to answer. One thing I can say having lived through many major software purchases is that the main cost was understanding a system that was purchased and that cost of understanding turned out to be far greater than expected. Large, expensive software products are often more costly to purchase then the price tag would indicate.
If you can gain a competitive edge through embodying it in software then it’s almost always better to build rather than to buy. This applies to entire products. Technology companies are sometimes purchased because of their customer base or inroads into a particular market segment or any number of other reasons. Of course, I’m not talking about off-the-shelf software. I’m talking about integrating essential components that were not developed in-house.
Have I learned anything in 21 years of professional software development? Well, yeah, a whole bunch of stuff! I’ve been paying some attention!
Some of it’s obsolete now, not least all the cool Excel stuff I could do before Microsoft excreted its damned Office Ribbon thing into the world thing leaving me unarmed and bewildered. But some of it could, perhaps, by particularly kind observer, be called some form of wisdom. Facts, anyway. Experience.
Good strategy requires clear objectives, so that’s always a good place to start before introducing something new into your organization. As a CIO or IT professional, maybe you’re already convinced of the benefits of citizen development and ready to get it moving. But where to start first? What is your vision for citizen development within your organization? What do you hope to achieve with citizen developers and a no- or low-code platform?
It is likely that many people in your organization will not yet be familiar with citizen development, and more still will need to be convinced of not only its value, but also its viability. You’ll have to convince them of the "why" for your pursuit of citizen development in order to educate, generate support, and keep an overall vision central for all stakeholders.
Value in the community lifecycle is tricky to measure. Value and how you define it depends on what stage of the lifecycle your community is in. It is ever-changing, from the first launch to growth to maturity. You need to prove the value of your community if you want it to stick around and more importantly, grow.
The first stage of your community is actually getting it launched. You will undoubtedly get questions about how the site is doing, whether it is growing, and how you can prove that it is succeeding. Luckily there are hundreds of different metrics and data points you can look at when starting up a site.
I’m catching up on my podcasts and just listened to Seth Godin’s Akimbo episode about honest signals. (Do listen.) It’s about the signals we send that are honest or dishonest and why we might choose one, the other, or both. I started to think about the management signals we send, especially in an Agile transformation.
In From Chaos to Successful Distributed Agile Teams, Mark and I developed this chart to show how Agile approaches change the culture.
A lot of poor designs can be attributed to sticking with an existing design as changing requirements show us the need for a better one. Oftentimes, an initial design is just a stab in the dark. We might not know enough to make an informed decision but we have to get something done, so we do what Agile says and we code up the behavior that we need right now and not worry about future requirements.
For most teams, the problem comes when they start to enhance that behavior and go back into the code to extend it. Now they’re asking the system to do something that it couldn’t do before and, instead of redesigning a feature to accommodate the new behavior, developers might try to hack in the new behavior while minimally impacting the existing design. But this can degrade the quality of the code when done over and over again in a system.
A while back, Jason Yip, tweeted about delivery of value and started an interesting thread.
Much of the discussion was about the definition of "value." Is it specifically about revenue generation or direct customer benefit? Is it more generally about any form of value such as revenue, progress, or learning?
Working from home has seldom been more popular, with a number of studies highlighting its potential for boosting not only our health and well-being but also our productivity. It’s tempting to believe that the debate has largely been run, and no further discussion is needed, but a recent study from Baylor University suggests we should not get too carried away.
The study examines the impact remote work has on the wellbeing of employees, before recommending a number of strategies to help managers better manage remote work opportunities that benefit both employer and employee alike.
I have been writing software at this point for over twenty years, and I want to believe that I have learned a few things during that timeframe.
And yet, probably the hardest thing for me is to start writing from scratch. If there is no code already there, it is all too easy to get lost in the details and not actually be able to get anywhere.
I’ve had this ongoing discussion with a few of my colleagues who say that the term “Agile leader” is an oxymoron — that the ideal organization is a bunch of Scrum Teams and not much else. Even in an ideal world, I disagree, and here’s why in a nutshell: I’ve never seen, and have not even heard of, an organization that was successful in their pursuit of agility who did not have a strong leader guiding the vision for what the organization can become, motivating people to achieve that vision, nurturing the pursuit of that vision, and protecting, when necessary, the people who want that vision from the people who don’t.
The reason for this is simple and is as old as civilization. As Nicolo Machiavelli observed,
Competition is widely believed to have a corrosive impact on trust, but what happens when that competition comes from a rival firm? Does the external "threat" bind us together? That was the conclusion reached by a recent study from the University of British Columbia, Princeton University and Aix-Marseille University.
The researchers collected data from the manufacturing sector in both the United States and Germany, and it emerged that the more intense the competition within the sector, the more likely it was for pro-social behaviors, such as cooperation and knowledge sharing, within each company.
Over the years I’ve heard my share of these kinds of statements from various levels of executives:
"When my guys run a product development release I really want to know what I will get at the end so I can make business plans accordingly."
The inventor of the World Wide Web, Sir Tim Berners-Lee, has launched a plan to build a “Contract for the Web” as part of a global campaign to defend a free and open web for everyone. Speaking tonight, at the opening of the Web Summit conference in Lisbon, Sir Tim unveiled a set of principles that define responsibilities that governments, companies, and citizens each have to create a better web.
According to the World Wide Web Foundation, the free and open web faces real challenges. More than half the world’s population still can’t get online. For the other half, the web’s benefits come with too many risks: to our privacy, our democracy, our rights. That’s why we’re launching a global campaign to connect everyone to a web that works for people.
It’s often said that we leave jobs in large part because of the bosses we worked under. There are many things about a bad manager that can prompt our wrath, but perhaps the foremost sin is to be workshy. New research from the University of Exeter highlights just how pernicious working under a lazy manager can be to our well-being and productivity.
The researchers wanted to examine the impact of having a lazy boss on the team working under them, both in terms of their mentality and productivity. The analysis revealed that leaders who regularly procrastinate both in doing tasks and making decisions result in lower commitment levels among employees. More worryingly, it also saw an increase in mendacious behaviors among staff.
“The important thing is to remember what most impressed you and to put it on canvas as fast as possible.” – Pierre Bonnard
Have you ever tried to kickstart a “Scrum of Scrums” in an organization? It’s an Agile activity which looks like it ought to be a no-brainer for teams…something they’d want to buy into, and of clear value to all. Yet after two or three sessions it will very often fizzle out. Only hard-core Agilists, those who care about the darned principle of this sort of thing, are left to wave their flag in the breeze. Everyone else seems to have more important matters to attend to than another piece of Agile “fluff.”
In our series around product management, the first blog about creating product backlogs addresses our persona discussion, where we established the handful of people we wish to impact along product development with their associated goals for use of the product. Now, we can take those people and goals and visualize the experience we wish for them to have. There are many ways to do this, but more times than not, we fall back to story mapping, which is another great practice from our friends in the UX community.
In the image below, you see that we have started by selecting a persona and a goal for our product development. From there, we ask, "What are the high-level activities that person will need to complete to accomplish the goal?" Once we have sketched out the activities from left to right, we can then ask for each activity, "What are the steps the user will have perform in order to complete that activity?"
I have been a technology architect for a long time and have worked with many different technologies. And there is something satisfying about coming up with "the architecture solution" for a business problem. The ideal end-state that, once implemented, will be perfect.
Unfortunately, I had to come to the realization that this is not true. There is no end-state architecture anymore and there never was. All those diagrams I drew with the name end-state in it — they are all obsolete by now.
Monday.com, formerly known as DaPulse, has been around the project management block for quite some time. Bagging some major clients including Fiverr, Discovery, McDonald’s and more, Monday has surely made its mark as a great productivity and project management tool, with over 10 years of history.
Monday is a project management tool with a multitude of features for team management and project delivery. So, why do we need alternatives?
In search of a sort of customer-centric product development Nirvana (and the organizational tenants that allow it to flourish) known as high-tech anthropology, executives are willing to pay upwards of $20,000 to spend time with the founders of Menlo Innovations, according to an article in Forbes. The Michigan-based software design consultancy has achieved Apple-like mystique with its unique philosophy that guides both how it works and the work it completes for its clients.
In fact, according to the Forbes coverage, a full 10 percent of Menlo Innovations’ $5 to $6 million in anticipated revenue for 2018 will come from the fees it charges for tours and consulting.
Lean and Agile practice are evidence-based and rely on the empirical delivery of value to assure predictability. Planning, development, and incremental release ought to occur on a short enough timescale, or cadence, to facilitate the inspection and adaptation of both product and process.
The even and consistent flow of work underpins this ability. Flow is enabled by a clear demand for completed work, the "pull" being propagated as efficiently as a team can manage across all of the stations at which value is added. Limiting "Work in Progress" helps to achieve this flow, and it is a very important skill to master. It ensures that work must be completed before anything new can be started. Each station should be given some sort of limit, such that anything below the limit indicates a capacity for new work to be brought forward. This helps to build pull across the value stream.
In 2010, the principal co-creators of Scrum, Jeff Sutherland and Ken Schwaber, agreed on the first version of the Scrum Guide, thereby creating the official BOK (body of knowledge) for Scrum. A few small, functional updates have been released since then. There have been no drastic changes to the core definition of Scrum. The updates are attempts to reduce complexity or have clearer terminology. Language and words do matter.
I imagine the difficulty of every rephrasing involved in updating the Scrum Guide. The Scrum Guide holds the single definition of Scrum for countless practitioners across the world, all employing Scrum in unique environments and varying situations. I imagine the discipline of updating the Scrum Guide knowing that many people will not read it. Most of all, I imagine the difficulty of updating the Scrum Guide knowing that many will micro-dissect the texts to identify the tiniest of changes. Many over-think individual words upon the misassumption of traps, tricks, and hidden messages. Many still look for methodological exactness and universal precision.
In their research paper titled ‘The New New Product Development Game’, Hirotaka and Ikujiro (both professors at the Harvard Business School) observed that the sequential approach to developing products is not best suited to the fast-paced competitive world. Instead, they recommended a rugby approach for enterprises to attain speed and flexibility to meet the ever-changing market requirements. The rugby approach refers to the Agile way (scrum) of working with practices like small batch sizes, incremental development, self-organizing teams, enhanced collaboration, cross-functional teams, and continuous learning. To put things in perspective, this research paper was launched way back in 1986! If the traditional approach was being questioned back then, it definitely needs to be relooked at now. Enterprises need to adopt agile practices to stay relevant in a market which has become extremely dynamic due to the proliferation of digital technologies. Agile practices enable enterprises to deliver solutions faster with better quality by considerably shortening the feedback loop.
Though most enterprises have realized the significance of Agile, most organizations, especially the large ones have been struggling to scale Agile at the enterprise level. This is substantiated by a recent survey through which it was found that the enterprises who had claimed to be Agile have admitted that they had adopted Agile practices only in certain pockets. Interestingly, smaller and nimbler companies have adopted the agile way of working and achieved considerable success in the market. These companies released products at a remarkable speed with high quality and reacted faster to the market needs. Take Tesla’s case (by no means a small company now!!), which launched electric cars with the auto-pilot option when the Toyotas and Bugattis of the world only had prototypes of electric cars. By the time they launched their own electric vehicles, Tesla had captured a huge pie of the market!! To the defense of these large enterprises, scaling Agile is easier said than done. These behemoths have many portfolios, with large applications requiring multiple teams, complex systems, diverse operating environments, and multiple vendors, making their Agile transformation journey a herculean task.
It is a good question: why do companies choose to adopt Agile? It is not easy to challenge old habits and refactor organizational structure. Some Agile principles are not intuitive and often meet resistance. The data supports that most adopters see significant benefits, but what are the reasons that companies choose to start the journey? Let’s look at the top five reasons from a recent survey conducted by Collabnet VersionOne.
The survey gathered responses from a variety of organization sizes, locations, and industries. There were 1,492 usable responses from Agile professionals. The top five industries from which respondents identified were Technology (24%), Financial Services (17%), Professional Services (9%) and Insurance (7%). (2018, Collabnet VersionOne)
One of the most valuable development practice that has become popular recently is test-driven development. When done correctly, unit tests can dramatically drop the cost of maintaining software while increasing its value. All the things that management wants and needs from the processes that are built around software development are embodied in this simple practice including consistency, reliability, and quality.
Code that has good unit tests tell us that it’s working correctly now and also tells us it’s working correctly in the future. Tests allow us to not only exercise the code in exactly the same way the application uses it but also documents its usage so we know exactly what to expect from the software that we write. Unit tests are contracts that express the expectations of the software they’re testing. Having a suite of unit tests in place for code allows us to automate a great deal of regression testing.
I woke up Friday morning at 3 am for the second consecutive day and yet again I couldn’t fall back asleep. The day before was the second and final day of my first experience co-training the new Scrum.org Professional Scrum Master II course. My head is full of new information and experiences which has seemingly created an endless loop in my brain.
I attended the PSM II course myself back in June at a Train the Trainer event at Scrum.org HQ ahead of its launch. It was a privilege to experience the course stewards Barry Overeem and Christiaan Verwijs facilitate the course in a way that I could only strive to reach. The experience was powerful and provided a mirror into my experiences as a Scrum Master. It changed the way I think.
The seventh Hands-on Agile webinar Scrum Sprint Anti-Patterns analyzed 12 ways a Scrum team can improve its effectiveness by avoiding typical sprint anti-patterns. Learn more about gold-plating, delivering Y instead of X, absenteeism, side-gigs, and organizing people instead of the flow of work.
The video of the webinar is available now:
Agile software development is a method used for developing all sorts of software solutions, based on continuous improvement, flexibility, input of the team, and high quality working software delivery. In this post, I would like to mention the main benefits you get by doing Sgile development.
Just a great idea is not always enough! Your budget and MVP must be planned together to achieve optimal results.
Whether you are developing a mobile app or a website, the cost of building an MVP varies on different factors: planning, design, features, technology stack, and time taken to build. There are various aspects to consider when deciding on a platform that compliments the Agile development process, and costs are based on this.
I’ve seen a number of individuals make transitions to new careers through all walks of life. Heck, I’ve seen English and History majors excel at IT consulting and end up being great senior IT executives!
It can be done just like Ray Kroc started McDonald’s in his early 50s. Nothing is ever too late.
With the soaring number of task management applications, finding the ideal tool can be time-consuming and confusing. The criteria for each tool depends on the organization, their needs, and requirements, as well as work processes. A range of features, ease of use, reliability, security, and expense can greatly affect your choice in management tools.
So how do you make sure you are investing in the right tool that can facilitate your task management without complicating work processes?
Most of the concepts in Scrum are easy to understand but extremely difficult to master. This is due to the fact that Scrum is designed for perfect, and reality never is. The same principle applies to the Definition of Done.
When we start up teams, we help them to set a Definition of Done (DoD). Teams are taught that the DoD is an instrument that will provide them transparency in two ways:
Aside from being accessible from any place and at any time, one of the best things about using an online Kanban board is the benefit of it being able to do things for you, remember for you, and to automate actions on your behalf. Without this, it’s only an online place where you’re keeping your to-do list, isn’t it?
So, what are the best ways in which using a Kanban board keeps your head clear and allows focus on the task at hand?
Naturally, you need these in order to know when each task needs to be done by.
I used to write software for a living. I did that for a lot of years, as a matter of fact. And, in doing so, I learned a lot about how to write software.
But I learned this from the perspective of, well, a wage software developer. Today, I’d like to reflect on how my view has evolved over the last number of years.
Too many software projects fail. Yup, we did it! Someone had to address the elephant in the room. Planning inadequacies and lack of communication are the essential reasons for the failure of custom software development, way more than technical incompetencies or unattainable requirements. Custom software development is far from quintessential and thus, the word “custom.” There might be a few similarities between some projects, but each project is a cluster of innovative ideas and business logic.
A recent Harvard Business Review article revealed that one in six IT projects has a cost overrun of 200%. Sounds like an industry that loves to fail. So, how can we reduce the expense of custom software development? Do it yourself? That goal is unreachable when it comes to software. And it is unimaginable to think that a modern business can prosper without software. As a result, costs skyrocket and eventually might even displace the company’s overall profit, especially for a startup and new small firm. Then, is there even a way to develop a custom software without losing all your money? Can we save costs in software development & maintenance? Absolutely.
Theoretically, open floor offices are a good idea. Sharing a spacious room would ideally provide a stage to plant fruitful discussions, develop & brainstorm ideas spontaneously and solve problems together.
Practically, however, many have a hard time concentrating in an open office – hence many sit there with headphones and listen to white noise to abstain from the distraction. As Joel Spolsky, CEO of Stackoverflow puts it, “programming is a solitary activity, and developers don’t benefit from overhearing conversations.”