Growing as a Product Owner: Five Product Owner Maturity-Levels

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:

Original Link

Custodians of Software Quality

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.

Code Quality

To achieve the code quality that will turn into overall quality, it is important that the code goes through the below processes regularly.

Original Link

Lowering Work in Process (WIP) in the Real World

One of the key Kanban practices we discuss in the Kanban Guide for Scrum Teams is Limiting Work in Process.

Some of us have the luxury of designing processes for greenfield systems, meaning there is no history/legacy to deal with.

Original Link

The End is Near!

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.

Original Link

Project to Product: What Flows Through a Software Value Stream?

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.

Original Link

Real-Time Operations Maturity: How Businesses Can Thrive In The Digital Era

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.

Original Link

Gestalt-Driven UX: The Patterns That Drive Our World

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.

Original Link

That Time I Deleted All My Meetings (On Purpose)

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.)

Original Link

Taking Your Company Private?

[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.

Original Link

Software Development as a Design Process

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.

Original Link

The Good, The Bad And The Ugly About Estimates

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.

Original Link

Maintaining the Status Quo: Custom Scalable Platforms vs. Low Code Platforms

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.

The Importance of a Good Foundation

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?”

Original Link

Buy or Build

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.

Original Link

Success Criteria: 21 Years of Software Engineering

Oct 2018: The fact that people — well, companies mostly — have been doing me the great courtesy of paying me to produce software for them for more than 21 entire years leaves me feeling incredibly lucky — and faintly horrified at just how quickly that time has passed. Increasingly often, new grads joining me in the workplace will be younger than the bugs I’ve left behind, so it seems a good time to pause and reflect!

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.

Original Link

5 Questions to Ask Before Launching Your Citizen Development Strategy

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.

Original Link

Defining Value in Community Launch and Growth

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.

Original Link

Management Signals

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.

Original Link

Code Transformations

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.

Original Link

Delivering Value

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?

Original Link

Why Should You Be Invited to A Meeting?

There was a Twitter interaction about testers being invited or not to team meetings and about providing value to the team.

And it got me thinking.

Original Link

Is Working From Home All It’s Cracked Up To Be?

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.

Original Link

The Fear of an Empty Source File

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.

Original Link

What Do Agile Leaders Do?

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, 

Original Link

How Competition Affects Trust In The Workplace

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.

Original Link

Risk-Aware Product Development (a.k.a. Scrum)

"There’s No Predictability/Commitment in Agile/Scrum"

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."

Original Link

Tim Berners-Lee Has a Plan to Save The World Wide Web He Invented

 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.

Original Link

The Effects Of Working With A Lazy Manager

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.

Original Link

A Digital Service Canvas for Government and Enterprise

“The important thing is to remember what most impressed you and to put it on canvas as fast as possible.” – Pierre Bonnard

Lessons From A Start-Up

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.”

Original Link

Creating Product Backlogs

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.

Visualizing the Product Story

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?"

Original Link

Three Architectures for IT Architects to Enable Agile and DevOps

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.

Original Link

5 of the Best Free Monday Alternatives (formerly DaPulse)

Introduction, 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?

Original Link

Easing the Adoption of A Customer-Centric Product Development Process with Data

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.

Original Link

Antipattern of the Month: Unlimited WIP

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.

Original Link

Scrum and Universal Truths [Update 2018]

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.

The Desire for Precision

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.

Original Link

Five Powerful Enterprise Agile Frameworks

Rugby Approach

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.

Scaling Blues

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.

Original Link

The Top Five Reasons Companies Adopt Agile

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)

Original Link

More on Test-Driven Development

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.

Original Link

PSM II: A Trainer’s Perspective

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 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 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.

Original Link

Webinar #7: Scrum Sprint Anti-Patterns [Video]

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:

Original Link

Benefits of Agile Software Development You Should Know [Infographic]

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.

Source URL

Original Link

Factors Determining The Cost To Build An MVP

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.

Original Link

Trigger Big Change by Starting Small With 15% Solutions

Liberating Structures are facilitation techniques that allow you to unleash and involve everyone in a group — from extroverted to introverted and from leaders to followers. In this series of posts, we show how Liberating Structures can be used with Scrum. If you’d like to experience Liberating Structures first-hand, make sure to join our Immersion Workshop in Amsterdam (December 10 & 11) or one of the other ones taking place in Europe in December.

"Even a 100-mile journey starts with a single step". This quote summarizes the power of 15% Solutions, a Liberating Structure intended to trigger big change by starting small. If you’re like us, you’ll recognize how easy it is to get lost in ambitious, over-the-top ideas that get bogged down in the realities of work. You may also recognize how easy it is to get lost in ‘Yes, but …’-thinking and focus on what isn’t possible. Either way, you can go easier on yourself and your team by starting small. After all, you can change the course of a river by changing the position of a few rocks.

Original Link

How to Make the Transition to a New Career

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.

Original Link

9 Features That Make a Great Task Management Tool

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?

Original Link

Definition of Done: The Swiss Army Knife of Scrum

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:

Original Link

21 Organizational Tools for Remote Workers

The future of work is here…and it’s setting up shop at a cafe, couch, or co-working space near you.

The amount of employees working remotely – and the companies making it possible – are continually growing.

Original Link

How to Make the Best Out Of Your Online Kanban Board

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?

Due Date Countdown

Naturally, you need these in order to know when each task needs to be done by.How to make the best out of your online Kanban board - due date

Original Link

How to Write Software: 5 Lessons Learned from Running Businesses

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.

Original Link

5 Effective Ways to Reduce Custom Software Development Costs

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.

Original Link

Programmer Interrupted – The Quiet Suffering in Open Floor Offices

Programmers Hate Open Floor Plans

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.”

Original Link