Archive | methodology RSS feed for this section

What Scrum Can Learn From Kanban – Metrics

Borrowing a page or two from Kanban, I propose that we can use the following additional metrics on our Scrum projects:

* Quality – number of bugs opened and closed per sprint
* Cost – the amount of money it cost to produce a feature or user story
* Lead Time – the amount of time it takes a feature to go from planned to implemented
* Feature Complexity – if you are breaking features into stories, you can measure how many stories it takes to complete a feature
(Link: What Scrum Can Learn From Kanban – Metrics)

RDV: a pressure cooker for usable business applications

Rapid Design & Visualization (RDV).

What is RDV?
RDV is an agile methodology for prototyping new business applications. If you practice RUP, it would start in the inception phase and probably extend well into the realization phase. RDV helps your IT projects to succeed by putting the focus on the end result rather than the process. This is achieved by doing very early simulations of that end result. In an iterative process, these simulations are developed and tested in close cooperation with real end users until the prototype is ready for the next stage: application development.
(Link: RDV: a pressure cooker for usable business applications)

Software Development in a Post-Agile World

So what is so great about process? Well, it gives us:
* Repeatable and predictable results
* Quality Assurances (through the above)
* Cost savings through the ability to optimise work flows
* Defined work flow allows us to use cheaper labour
* The promotion of best practices and conceptual integrity
* The ability to scale to large numbers
* A means to effectively track our progress against the objectives

Process is sometimes inappropriate or unconstructive. Process can:
* Increase cost and reduce performance through bureaucratic overhead and waste
* Hinder our ability to change or adapt to new situations
* Stifle our capacity for innovation and creativity
* Require discipline and training which takes effort
* Only effectively be applied to known quantities
(Link: Software Development in a Post-Agile World)

Bringing User Centered Design to the Agile Environment – Boxes and Arrows: The design behind the design

UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go.
(Link: Bringing User Centered Design to the Agile Environment – Boxes and Arrows: The design behind the design)


Follow

Get every new post delivered to your Inbox.