Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.
Agile / Communication / Consulting / Process Improvement / Project Management / Requirements / Software development
Posted on:
Scheduling requirements changes – part 2
This process goes against agile principles on paper, but makes teams more agile in practice. Scheduling delivery of a project is an exercise in managing complexity. Scheduling changes to the requirements on the fly is really only marginally more difficult. The key to managing changes is to set expectations with our stakeholders. By defining rational deadlines for change requests, we assure ourselves that we can manage the changes. We also demonstrate responsiveness to our stakeholders. Rational deadlines are not arbitrary deadlines nor are they unreasonable deadlines. Deadlines that vary with the complexity of the changes are rational, easy to communicate, and easy to manage.
Agile / Communication / Consulting / Process Improvement / Project Management / Requirements / Software development / Use Cases
Posted on:
Scheduling requirements changes – part 1
Software product success requires timely delivery. There are many factors that influence our ability to properly scope, schedule, and deliver software. When we propose changes in requirements we introduce risk to the schedule. We can set reasonable expectations for our stakeholders while maintaining a realistic work environment and schedule. In part 1 of this post we detail a requirements triage process that organizes requirements by complexity and allows us to set and meet expectations of delivery.
Product Management / Requirements / Requirements gathering
Posted on:
Product Manager Role Definition
Michael has posted a great definition of the product manager role on his blog, Product Management and Product Marketing – A Definition. He covers a whole host of activities in six seperate areas. Some of the responsibilities, while not product management, are often the responsibility of the product manager. It’s a good real-world assessment of what product managers are often asked to do.
Interaction design / Usability / UX
Posted on:
Office 2007 UX Victory
Microsoft Office 2007 has a completely new user interaction paradigm.
The old interfaces for Microsoft Office 2003 (and earlier) organized the menu structures around features or capabilities. Each grouping represented tasks that appeared to be related in functionality. This, unfortunately, doesn’t help the user very much. The new interface is very task based, and organizes capabilities based upon the task the user is currently performing. What the Office team has done is innovate. And the innovations differentiate them from every other business application I’ve ever seen.
Prioritization / Product Management / Requirements
Posted on:
Epicenter software design – 37signals applies Kano
Jason at 37signals has started a discussion about feature prioritization with his recent post. He describes the epicenter of software as the most important, must-have feature. He argues that this feature should always be the one that is built first, since without it you don’t have an application. This is the same approach we reccommended in our recent post about prioritizing requirements with Kano analysis. The epicenter, while critically important, isn’t sufficient to drive success for the software.
Communication / Consulting / Outsourcing
Posted on:
Outsourcing Conversation – One Topic, Two Blogs, Three Cs
Frederick Boulanger picked up on our earlier post about different outsourcing process models, and extended it with his own good ideas- making it easier for teams to decide which outsourcing model is right for them. Frederick identifies the three key factors that determine which model is most likely to succeed for a given team. They are control, coordination, and communication. Anyone else want to join in? Blog away, and trackback or comment here.
Process Improvement / Software development / Test Automation / Testing
Posted on:
Learn to Fly with Software Process Automation
We can reach the next step in our software process evolution by automating much of our process. Flying squirrels evolved a technique* to quickly move from one tree to another without all the tedious climbing and dangerous running. Software teams that automate their processes achieve similar benefits. Automation allows us to increase efficiency while improving quality. And we spend less time on tedious and mundane tasks.
Communication / Lists / Presentation / Writing
Posted on:
Targeted Communication – Three Tips
Most guides to writing an executive summary miss the key point: The job of the executive summary is to sell, not to describe.
This from Guy Kawasaki’s recent post, The Art of the Executive Summary. Guy’s article is structured towards pitching an idea to a potential investor. We’re going to apply the same rationale to the communication that is key to successful product development – communication from the team, to stakeholders and sponsors.We also communicate with people outside of our team. We communicate to set expectations with customers, users, and clients.We communicate with sponsors, customers, and others who fund our software development. Without these channels of strategic communication, we won’t have a project, or worse, won’t have a customer when we’re done. External communication is strategic communication.