It is critical that everyone has the same understanding of, and commitment to, the desired outcome: a business that is reliable through predictable technology processes that deliver business agility. To do this, there needs to be a management commitment to develop a focused, on-going practice around the pursuit of organizational maturity. As part of this, gaps in skills and capabilities should be identified and positive action – training, coaching, process improvement and tools deployment – taken in order to close the gap
Creating an Agile Culture to Drive Organizational Change - 1 views
-
-
the work force needs to understand the business drivers for Agility. They need to be challenged to improve their quality, improve their cycle times, to improve the frequency of releases and the value they deliver to the customer. They need to know how these things fit within the bigger picture and why improvement is their responsibility.
-
To change a culture it's important to recognize that every knowledge worker makes decisions and takes actions that affect the performance of the business. The culture in the organization is the reflection of those decisions and actions.
- ...14 more annotations...
Managing WIP isn't the same as Limiting WIP: Part 1 - 0 views
-
To determine the truth of this we only need to look at the feature sets of the popular tools for managing eXtreme Programming and Scrum such as Rally, VersionOne, ScrumWorks, Mingle and very new tools like Borland Team Focus, to discover that not a single one of these tools allows you to set an explicit WIP limit. None of them provide a pull signal to start new work. Very few of them are even capable of reporting the quantity of work-in-progress.
-
s we learned more about the value of managing WIP, we introduced concepts to encourage and enable it, such as the use of Cumulative Flow Diagrams (a.k.a. Burn Up charts)
-
Agile teams encountering an impediment would generally mark a story as blocked and go on to another one
- ...2 more annotations...
CIO Perspectives: A Conversation on Agile Transformation, Part 2 - 0 views
-
Part 2
-
The thinking is that IT is mission-critical, so let's not change things without giving it a lot of thought and a lot of consideration
-
The really hard part is around the people transformation - getting developers to work side-by-side with testers and users is a completely foreign concept.
- ...8 more annotations...
Original Scrum-ban Article by Corey Ladas | Lean Software Engineering - 1 views
-
A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable.
-
then you need another mechanism to regulate the “money supply.” In our case, we simply write the quantity of kanban in circulation on the task board, and allocate new cards according to that limit.
-
You might have a simple principle like: prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6.
- ...6 more annotations...
James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views
-
when you first create a design element—whether it's a new method, a new class, or a new architecture—be completely specific. Create a simple design that solves only the problem you face at the moment, no matter how easy it may seem to solve more general problems
-
Waiting to create abstractions will enable you to create designs that are simple and powerful.
-
The second time you work with a design element, modify the design to make it more general—but only general enough to solve the two problems it needs to solve. Next, review the design and make improvements. Simplify and clarify the code. The third time you work with a design element, generalize it further—but again, just enough to solve the three problems at hand. A small tweak to the design is usually enough. It will be pretty general at this point. Again, review the design, simplify, and clarify. Continue this pattern. By the fourth or fifth time you work with a design element—be it a method, a class, or something bigger—you'll typically find that its abstraction is perfect for your needs. Best of all, because you allowed practical needs to drive your design, it will be simple yet powerful.
- ...12 more annotations...
1 - 9 of 9
Showing 20▼ items per page