2013 06-software product engineering conference
•Download as PPTX, PDF•
1 like•264 views
Presentation held at the Software Product Engineering Conference in Colombo, Sri Lanka. Download to see speach notes.
Recommended
Recommended
More Related Content
What's hot
What's hot (13)
Viewers also liked
Similar to 2013 06-software product engineering conference
Similar to 2013 06-software product engineering conference (20)
Recently uploaded
Recently uploaded (20)
2013 06-software product engineering conference
- 2. Would you tell me, please, which way I ought to go from here “
- 4. Detailed requirements Use cases Test cases Wireframes Change requests Change requests Scope creep
- 5. Backlog grooming Discussions Planning Demo Adjusting Retrospective Backlog grooming Discussions Planning Demo Adjusting Retrospective Backlog grooming Discussions Planning Demo Adjusting Retrospective Backlog grooming Discussions Planning Demo Adjusting Retrospective Backlog groomin Discussions Planning Demo Adjusting Retrospective
- 8. For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)
- 14. Image from blog.yammer.com the project Running
- 16. 1 2 3 n Delivery 1 2 Delivery n Ideal Reality the project Delivering
- 17. Accept and embrace change Engage users throughout the project Build trust with project sponsors minimum viable product Continuously focus on business value and efficient tools Use and communication
Editor's Notes
- Lean requirments management Requirement capturing throughout the project: - creating vision - deriving a product - establishing the project - running the project - delivering the project How I have practiced that Why I have practiced that What the value is SO WHAT IS THE CASE HERE?
- There is a famous scene in Lewis Carroll’s fable about “Alice in Wonderland”. Alice falls down a rabbit hole, and find herself in a strange fantasy world where common sense fails and many bizarre situations occurs. Trying to figure out what to do, she meets a cat who is sitting up on a tree. She asks the cat: "Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to," said the Cat. "I don’t much care where--" said Alice. "Then it doesn’t matter which way you go," said the Cat. "--so long as I get SOMEWHERE," Alice added as an explanation. "Oh, then you’ll get there," said the Cat, "if you only walk long enough." Being in a midst of a software development project - whatever method you choose to use - is like being caught in a world like Alice’s. You definately end up SOMEWHERE, but often not where you thought you would. Lean requirements management is a lot about accepting this uncertainty, walk down the road of future insecurity, and embrace the changes that will come. And not be threatened by it. And believing that the road evolves as you go, to ensure maximum value for the end product.
- The balance between predictability and unpredictability is constantly shifting throughout a software developement project. Life is like this. We plan, but are hopefully open to what the future brings. And we live our lives inspecting and adapting to our surroundings. Those in need of detailed control of their life are often to be found in institutions, since this kind of control is not good for us. A good life is to accept uncertainty, and embrace change. This is reality in software development as well. It is about adapting to the ever-changing surroundings, and ensuring whatever we create is of value to the user. Agile methods is a lot about life, in this sense. But in a software development projects you have some specific challenges: - stakeholders - users - project sponsors And especially the latter - who are funding the whole show - want to know what they get for the bucks. SO HOW CAN WE ADRESS THIS UNPREDICTABILITY?
- History of traditional waterfall method has shown, though, that you really don’t exactly know at the end of the day what you get. The future is unpredictable, and no detailed specification can embrace the need of change that WILL arrise. So we have initially detailed requirments, use cases, test cases, and get a sign-off. Documentation was excessive. The specification was the promise and the contract. Wireframes to get acceptance from the user. Assumption: requirments are not going to change for the entire lifecycle of a product release. Based on this we make predictions on cost - time - quality , resulting in a promise. A delivery. In time, within budget. Very soon we get scope creep. Someone turns out to be the scapegoat ones the change requests are coming. And to facilitate this, we create even more documentation for the change requests, new sign-offs, delays, and worst case quarrels about implied requirements. This is some of what was addressed in the Agile manifesto in 2001: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan
- Agile methods changed all this. Focuses on creating value. And emerging and constantly gathering requirements. Iterative processes. We write short stories. We groom a backlog. We plan. We discuss. We develop. We show off. Requirements are gathered on the fly. We deploy minimum viable products and validate the work with working software. We discuss how to be better in the next iteration. We document not for the sake of documentation, but for the sake of working efficiently together. But: it IS uncomfortable for many stakeholders, especially for the sponsor, to not have a precise description of what he gets. But this is where communication awareness starts. It start by being on the same vessel. First risk is that communicating scope and estimations can fail if the sender is in the realm of lean, while the recipient is in the realm of waterfall. So how do we address this potential discomfort? How do we convince ourselves and others that this is the way to go?
- Creating the vision Every projects like this has visions. But are they shared? Case Centric Dutch company 5300+ employees Netherlands, Belgium, Germany, Romania, Norway, Sweden. IT Developement Services Consultancy Staffing recruitment Many companies. Different systems. Bring together.
- Creating the vision – the start of all requirements capturing. But also: The mother of all implied requirements. Has to be in place for all product development. Product outcome. Vision alignment. Our case: Top-level anchored. They wanted one system. And shared processes. Even though same business (staffing & recruitment): "Envisioning a product" = "Optimizing my workspace and processes" <=> "Enabling the enterprise to deliver more value to customers" <=> “More collaboration” Other effects: does the user really know what he wants? Henry Ford: “If I had asked people what they wanted, they would have said faster horses.”
- If your top management doesn't share the product vision, then don't waste your time. Select another project. Purpose of elevator statements. Sharing vision How to share visions: elevator statement or product box Get domain knowledge Our elevator statement: For all Centric companies Who are in need of a new staffing- and CRM-system Our product is a staffing system that will gather all of Centric divisions in to one common system Unlike all the different systems in use today, Our product makes it possible to collaborate across all divisions. ONCE A COMMON VISION IS IN PLACE YOU NEED TO DERIVE A PRODUCT.
- Deriving a product Our case: Not commercial, but internal. So everybody “owns” the system in a different way than a commercial product. A lot of politics. Process discussions. Different levels of maturity – both on system and process. Obviously: would be a lot of discussion. WE NEEDED A ROADMAP; A HIGH-LEVEL DESCRIPTION OF DIRECTION.
- Focus on delivering value - early. And still question: What's inside and what's outside scope? Based on epics: Value creation map - showing the most valued features on top. Identifying the minimum viable product. Not a WBS ONCE THE CONTRACT WAS SIGNED, WE HAD TO ESTABLISH THE GROUP AND GROUND RULES.
- Establishing the project Importance of a strong PO The Product Owner is everything else but a Project Manager. He is the missionary, the general, the politician. Needs to be present amongst the users Needs to push Fulltime job! Important "man in the middle" Should not take vacation Has to be very communicative ONE OF THE FIRST THINGS A PO MUST DO IS TO ANSWER THE QUESTION: WHO SHOULD BE IN THIS BALLGAME?
- Get requirements from the right people. Identify the stakeholders – stakeholder analysis But a slight difference. High/Low Power: the stakeholder’s ability to affect the project and project outcome. High/Low Impact: the impact the project has on the stakeholder’s work Traditional stakeholder analysis is about communication. Can also be seen as requirements gathering. Once identified the key players: create the user group
- Establishing the user group Is the User Group your steering committee or…? They can have a lot of opinions, but no commitment. Needs to get engaged! How often Who – Earned it, Representation,””Business Unit lawyer” Function Victimization Ambassadeurship • The User Group: victims, ambassadeurs, or story tellers? How to engage Difficult More for "show and tell" The need of a smaller group for the actual User Acceptance testing. Agree on main flows, lists, aligning the users The importance of face-to-face workshops RUNNING THROUGH THE LIFECYCLE OF THE PROJECT IS BEING CONSTANTLY ALERT AND USING THE CORRECT TOOLS.
- How to get feedback from User • Discussions over documentation, yes. But document the discussions. What feedback can be expected? Different types of communication in agile projects Information Collaboration Notification Avoid email!!! (we denied this in our project) Tools Wiki. Avoid documents. Discussion forums. Mentioning. Social enterprise. Example: Confluence Backlogs/issue/workload. Burn-down charts. Discussion. Link to Wiki. Example: Jira, Team Foundation Server (latest version). Social enterprise tools: Yammer Skype Cisco
- How do I know the real value? The value of demo contra "hands on feeling" Emphasis: being able to deliver often for UAT After a short while: risk: "Everything goes" syndrom One thing takes the other Other depts/BU wants to jump on Dissolving the purpose of the application The backlog "The winner takes it all" First one out gets the most • The product backlog: a fight amongst the users or a groomed list of value deliveries? Addressing responsibility for the whole picture and enterprise value
- Focus on Minimum Viable Product: On commercial products: -time to market decreases. Creates revenue – faster ROI Can move forward and reinvest profits. Reality The challenge of frequent deployments when it's all about replacing an existing system(s) BUT: During development: always working software. Focus on minimum viable product. Though not deployable.
- So to summarize: Accept and embrace change Engage users throughout the project Build trust with project sponsors Continuously focus on minimum viable product and value Use efficient tools and communication