"After giving the organization a purpose, acknowledging the autonomy of workers, and ensuring the connectivity of people, the fourth thing to do is to create transparency in the organization"
"Formal authority can be stifling, but creative authority is the source of the passion in a company. There’s very little with more vitality than someone pursuing their vision — just watch an early stage start-up founder in action. But give it away and the energy begins to drain."
"The most important early warning signs are intangibles. The earliest signs a project is in trouble are hard to measure objectively, but easy to spot if you watch for them. Two of the most important, Jim Johnson says, are lack of interest in the project and chronically poor communications."
"Nothing beats face to face. The sheer amount of information being shared and the number of decisions being made during PI planning is actually quite astonishing. This is possible because all brain trust and empowerment is summoned in the same room at the same time. Anyone you need to talk to is right here in the room, right now."
"In a development world, it is easy to see who the end customer is. However, in a non-software world, identifying customers may be tricky. Typically, these are the stakeholders that have direct or indirect interest in the initiative. However, unlike the end users of a system, this set of customers may have conflicting priorities, internal biases or preconceived notions. That many of these stakeholders are senior management and even C-level executives makes this task even more difficult. Choosing the 'right' Product Owner, who can rein in these complexities, is most crucial."
"Brainstorm every feature in a small group of 4-7 people. Invite developers, invite testers, invite designers, invite product specialists. Invite everyone who has diverse skills and can contribute to a discussion."
"Instead of spending mindless hours recording what has been and will be done, agile teams focus on the actual product. Instead of approaching the product as a whole, the agile method emphasizes functionality."
"Delegation is not a binary thing. There are shades of grey between a dictatorship and an anarchy."
"Complex systems fail in complex ways. But all start with human failings.
[...] Rather than countering complex risk with an even more complex risk-management system, which comes with its own blind spots and brittle places, leaders have to equip the individuals in their charge with common levels of risk awareness, codes of conduct, and value systems.
"Salesforce was able to succeed with Agile, where many others had failed, because they adopted the values of Agile, not just the practices, and so did not fall into the six common mistakes that many other firms have made, because they only adopt the practices of Scrum, not the values of Agile."
"Agile delivery is imperative for non-software projects due to their inherent risks and complexities. Models may vary, but the concepts of Agile do not. Instead of aligning to prescriptive Agile methodologies, we need to align ourselves to the overall Agile manifesto"
"We spend a lot of effort on knowledge sharing: every week someone from our team writes a knowledge sharing digest with all the recent information that could be useful."
"A culture of trust in your company will slowly return a person’s trust in themselves, encouraging them to experiment and make mistakes. A culture of trust can help you to grow not only as a worker, but also as a person. With time, people will be able open up and find new sources of inspiration."
"Yes, Product Owner is responsible for the product. Yes, he knows a lot. Yes, he can solve problems. And, yes, you expect too much of him. It is quite unusual to expect the best solution from a single person. It is always better to have a small group of people with various skills, various backgrounds, and various focuses to find a great solution."
"Risk Management isn't just about foreseeing and preventing losses. It means adopting an attitude, more or less consciously, in order to protect yourself against negative events (threats) and take advantage of positive events (opportunities). Once you have properly analyzed a scenario, you will be able to identify these threats and opportunities before they even happen. "
"Values and principles scale, but practices are context sensitive. We all know it is hard to improve, but we know that we cannot buy our way to a better future."
"The need to accommodate eclectic teams, on the other hand, is linked to increasing specialization that one finds in any startup as it grows. Once marketing, support, and operations folks get into the flow, it becomes painfully obvious that, in addition to a set of common practices embraced by the entire company, they also need a unique methodology for dealing with ‘local’ tasks. For example, setting your task status to “shipped” might make a lot of sense when developing a new feature, but it is useless in describing an ongoing marketing campaign."
"The consequence of this non-policy policy is that your work must speak for itself. It’s not about face-time, a race to the office in the morning, or a competition to see who can be there the latest… output is what matters. Zaarly is not a place to hide. It is a place to produce."
"The vagueness of the term agile can be a deterrent. Asking "Are we doing it right?" (or the more likely scenario - telling someone else "You're not doing it right!") is not a very valuable question. "Are we learning all we can?" and "What do we need to change to most benefit our company's goals?" have a lot more impact. If agility is a mindset, then measures of correctness don't really apply."
"Stop measuring work in hours and start measuring it in output. Most knowledge workers aren’t paid by the hour. They’re paid a flat salary because their employers aren’t buying the ideas they have from 9-to-5; they’re buying the ideas they have in the shower, during lunch, and before getting out of bed."
"There's a price to pay for all this progressive, initiative, risk-taking way of working. We are going to periodically fail. We can't build innovative software or create great products without periodically going over the edge. It's very important for the organization to develop an appetite for risk and accepting failure as an essential derivative in order to deliver quick business value. "
"Using a tool that doesn't match your process is useless, and using a good tool on top of a bad process will only accelerate poor results."
"The shift to Agile is not just a matter of adopting one or two particular management tactics. Agile involves a radically different kind of management with a different goal (delighting the customer), a different role for managers (enabling self-organizing teams), a different way of coordinating work (dynamic linking), different values (continuous improvement and radical transparency) and different communications (horizontal conversations). A single fix is not enough: companies need systemic change."
"Context switching should be reduced to a minimum. The best scenario is to work on a single task till completion and only then switch to a new task. Easy to say, hard to follow."
"Once everybody agreed on how we wanted to work, coming up with criteria for selecting a new PM tool was very straightforward. We thought that the software should be intelligent enough to support agile methodologies and flexible enough to accommodate eclectic teams under one roof."
"Give people the tools to focus on making customers lives better, and throw away everything else. So, get rid of organizations, get rid of titles, put everybody's desks on wheels, and just say ‘here are the tools you have so you can tell whether you are doing a good job or not,’ and support people as much as possible with the colleagues and tools they need to do that."
"Managers laugh when I tell them of an organization I once heard of that offers an annual prize for the best mistake made last year. That mistake is defined as the one from which they have learned most. When August Busch III was CEO of the Anheuser Busch Companies, he once told his assembled vice presidents, ‘If you didn’t make a serious mistake last year, you probably didn’t do your job, because you didn’t try anything new. There is nothing wrong in making a mistake, but if you ever make the same mistake twice, you probably won’t be here the next year.’ He had it right: Mistakes will be forgiven if we learn from them."
"An all-in transition will almost certainly cost more than starting small. Because of the greater number of people learning a new way of working all at the same time, all-in transitions generally rely more heavily on outside coaches, ScrumMasters, and trainers. The slower pace of a start-small adoption allows the organization to build internal expertise and then use that to help the scrum teams that start later. Starting small also saves money because early mistakes affect only a subset of the organization. Tom Gilb, who was perhaps the original agilist, has written, ‘If you don't know what you're doing, don't do it on a large scale."
"Software developers and writers share many traits. They need to blend creativity with science. They need to collaborate, yet go heads-down with focus on their individual tasks. And they don’t like people looking over their shoulders and micromanaging them. Figure out what your content marketing team members need to be successful, provide it, and trust their commitment and motivation to get the job done."
"Working remotely is great, but it can get lonely. Even worse, it can be technically isolating. If you don’t have solid communication practices built up at your company, you run the risk of leaving your remote workers with an information gap that will impede them from performing their jobs."
"A core premise of agile is that the people doing the work are the people who can best figure out how to do it."
"Narrow an individual's scope of authority, and you shrink the incentive to dream, imagine, and contribute."
"In cultures where there is an urgency to see results, the benefits of planning are often forgotten until it is too late. A former colleague once ruminated that his organization never appeared to have the time to plan, yet it always found enough time to do the project twice."
"Agile programming doesn’t just mean doing more work with fewer people."
"From Lean software design we take the concept of using less stuff wherever responsible. This is based on the common-sense mandate to “use less stuff,” which is then defined in a clear, applicable way by the contemporary software team. From Agile software development we take the principle of reducing cost to make change—changes in team, materials, machinery, and even goals. From Scrum software development we take clearly defined team roles and responsibilities, which allows us to spend more time rapidly developing product with no nonworking (management only) roles and only two meetings."
"If we have already decided that the new guy is a stupid jerk, and thereafter we only look for evidence to back up our evaluation, we’re not going to see anything that negates our belief. We will only see poor performance. That can definitely get in the way of collaboration."
"Agile is more about how a team approaches solving problems by working collaboratively while quickly adapting to changes and less about the tools used to support that approach. While tools (morning stand-ups, using story points for estimation, and tracking progress on a burn down chart) are part of the agile process; they are not necessarily indicative of an organization with an agile mindset."
"It might appear that there's some correlation between volume and completeness. But it's hardly a good idea to pour extra water into a specification. Just fill it with common sense."
"Retrospectives allow us to look back and learn so that going forward we build on successes and account for things that didn’t work so well. The notion of small experiments is something I’ve been focused on lately. I encourage teams to come to retrospectives, not with problems, but with ideas for small experiments to run in the next iteration."
"The key in such a transition to continuous delivery is to expect things to get worse before you’ll be able to make them better."
"If you are looking for an example of agile in your domain, unless you work in software, there might not be one yet. That is a double-edged sword. It means that if you want to apply agile, you will need to think more carefully and be prepared for more risks. But it also means there is greater potential benefit because others have yet to forge this path. Adopting agile could carry a bigger reward for your organization just because competitors aren’t using it."
"We make attributions about each other’s motives and intentions and hold other parties accountable for the difficulty when we find ourselves at odds with one another. [...] Most everyone can think of an example of this behavior, often accompanied by a juicy story. What is often left out of the story is the teller’s complicit participation in it. There is no awareness around how he or she might be involved in creating the secret, the undiscussable, or the elephant. These dynamics become a routine part of the workplace culture."
"Rituals are not inherently bad, but problems arise when there is blind adherence to rituals without an appropriate framework for continuous self-evaluation."
"A good starting point is to make a list (literally) of all the things that a manager does, and then figure out how your process or system is going to deal with that,"
"Domain knowledge is crucial for any software developer. It helps to understand problems deeper, create better solutions faster, and reduce re-work. It allows developers to spot bad solutions earlier. Without domain knowledge, developers will blindly implement a solution provided by business analysts or product owners. With a good domain knowledge a developer can easily invent an excellent solution by himself or be a part of the UX team to brainstorm solutions."
"Documenting the reasons behind requirements will give your team invaluable information when making daily implementation decisions."
"For project and portfolio managers just getting started with Lean principles, Rothman said start with small chunks rather than the big picture. And most important, she said, “Keep teams together and have work flow through projects. If that’s the one thing you can do, do that. It will get you the biggest bang for the buck."
"Handoffs are mostly a result of specialization. Organization design cannot reduce these handoffs, but it can make them faster and cheaper by making them occur inside a single team."
"Plans are of little importance, but planning is essential."
"Move your focus from the organisation or company itself with its formal org chart, and instead focus a layer deeper on the creative order beneath. In other words, the underlying initiative to realise an idea. Acknowledge and work with the natural hierarchy of the creative order which emerges and grows as an idea gets realised."
"While some managers say that they can't afford to put a user on the team, doing so is like building a custom house without being willing to actually visit the site during construction. Nobody would do that with his own home. Why would you let that happen with your IT investment?"
"The Agile Manifesto emphasizes that none of the authors believe in a “silver-bullet theory,” hence why nailing “What Is Agile” gets so complicated; the founders did not think that they had all the answers, and they didn’t think there was a perfect one-size-fits-all methodology for every development team. Their approach was necessarily libertarian"
"Over the past 25 years, retailers and brands have obviously exploited sourcing and distribution efficiencies. What is different about retailers like Zara, H&M and Uniqlo is that they combine low cost production with speed to market and customer-focused agility. The key is to combine improved speed and efficiency across the entire product cycles driven by what customers actually want, not just inward-looking cost-savings in part of the supply chain."
"Creating the right sense of teamwork can be challenging. ScrumMasters can help by ensuring that the team embraces the concept of whole-team responsibility and whole-team commitment to deliver working software at the end of each sprint. Though the team might struggle at first to break longheld habits of specialization and handoffs, increasing communication, decreasing the size of handoffs, and mixing the size of backlog items brought into a sprint will help individuals make the shift from sequential development to working as a team."
"No matter how strong the temptation to obsess about conversions or short-term hacks, we need to understand that what lies behind sustainable growth is our ability to delight our customers with our dedication to extreme value creation."
"Without a solid background in the domain, you can’t expect a developer to be able to make good decisions with their freedom of choice, even if they are a responsible person. Freedom of task selection in the context of domain ignorance is just harmful."
"Requirements changes, per se, aren't a bad thing. In fact, they're pretty much expected in the agile method because of the constant user feedback the process produces. Indeed, changing the requirements can be a healthy thing. The questions are which requirements are changing and why. The answers can tell you a lot about the health of the project."
"I have come to believe that the main reason many efforts to go agile fail is because practitioners tend to forget that the manifesto is a statement of utopian ideals to aspire to. Any prescriptive practices that come out of it like Scrum and Kanban are simply practical attempts to stride towards this ideal however, due to the nature of the principle, none of these practices can ever actually get to the ideal. [...] The reasons that many project managers fail to succeed in agile is because they are looking for something to DO to achieve it. Being agile is not about keeping control of a project through Scrum/Kanban, it’s about hiring the right people for the job and allowing them to naturally discover the optimal project configuration to deliver successfully."
"Although we didn’t follow “proper Scrum” after that, we absorbed many of its principles and protocols into our own project management methods. We weren’t following any established framework to the letter, but we really did believe in the core principles of Agile, and we saw ourselves as an Agile design firm."
"Interruptions are the enemy of productivity, and group chat has become the greatest interruption factory at work. If you want people to do great work, you have to give them the appropriate time and space to get into the zone. Chunks of time — 15 minutes here, 30 minutes there, 7 minutes here — aren’t going to do it. People need hours of interrupted time. Every time that unread indicator appears, it’s temptation for people to break away from what they’re doing to check in. Be mindful of the cost of those interruptions. Are they worth it?"