The road to Inner Source
The key to success lies in numbers. Group of people working together to achieve a goal, determines the outcome. It creates a synergy which is not possible with individualistic mentality or people working in silos.
Inner Source is one such recipe of collaboration and success. Inner source allows the development of open culture within the context of organization.
In this session, we will look at how organizations can take part in this movement and what are the crucial aspects which will eventually determine the effectivity of inner sourcing.
Outline/structure of the Session
What is Inner Source
3 P's of Inner Source
Audience will have a better and clear understanding of what inner source is all about. How big organization can take advantage of this powerful movement by taking advantage of open-source like freedom without compromising on security, corporate policies or confidentiality.
Open for everyone.
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Dany Poudrier - Story Mapping - Mom, where does baby User Stories come from? Part 1
How do Product Owners create Epics and User Stories?
Simple question, right? If you Google that, you will get dozen of sites telling you what it should include, the format it should take and the principles it should follow. Fair enough...
So how come your backlog still feels like a vertical pile of Items you hope contains everything to satisfy your customer?
This talk is intended for Product Managers and Product Owners that wakes up at night in sweat because they have so many current and future user stories to think about with dependencies, MVP Journeys and bugs to order in a vertical one dimension Backlog.
Dany Poudrier - Agile Product Managers - Mom, where does baby User Stories come from? Part 2
Did you ever asked one of your developer: Can you tell me what Business Initiative your current developed User Story helps to implement? How about you, can you identify it?
Do you feel that your Epics are just way too big? Thin Slicing Epics is a good practice, but how do you link them all together as one?
As a Product Manager or Product Owner, do you have a lot of Epics or Stories that are in your backlog for more than one year and you never touched them because "you know you will someday"?
Your development teams are Agile, how about your Product Management Team?
This talk is for Product Managers, Architects and Product Owners that feels that life is more than 3 Level of granularity (Epic-Story-Task). We will tackle in this talk the Product Management Feature Backlog based on the SAFe Framework and the Definition of Ready.
Dany Poudrier - Business Value - The sum is "only valuable" as the addition of part
Are you using Business Value to order your Backlog? The Return On Investment ( Business Value / Story Points)? Probably not.
I think it is because we confuse Value with Business Value. Or more importantly, what Business Value means.
Stories are supposed to follow the INVEST principle, true. So they should be Independent and add value. You can argue that a Search Mechanism and a Create mechanism have similar value. Now go tell your client that he can have Search only without create, you will probably get a This doesn't add Business Value for me. Now tell him that he can have Create but no search (so no way to find the created item), you will probably get the same response. Only by having the two Stories completed you enable the Business Value from being released. The User Journey of Create and Search is the real Container of Business Value. The value of Search and Create independent story is good for PO and maybe beta testers, but real users will only use your tool if they can complete a User Journey. They may test your tool, but will not use it.
What does that mean for you and me as Product Owner? That we should focus on User Journey to order our backlog. Because only the completed sum of the Stories that makes a User Journey truly hold/unleash the Business Value for customers. You only deliver Business Value to your product if your customer can use it to solve a business need
Dany Poudrier - Let's cross the finish line all at the same time
This is the story of how Autodesk's Fusion Lifecycle Product teams broke down the Feature Team silos and really worked towards maximizing the delivered value to customer.
Autodesk is implementing Release Trains based on the SAFe Framework. The Fusion Lifecycle has 6 development teams in 4 different countries with 3 different timezone.
Each team was "owning" a set of features. So feature specific bugs or enhancements would be automatically assigned to the right feature team. And each Team has it's own PO to order their team specific backlog items.
We are calling it "peanut butter spreading". 6 Teams, 6 features so we thought "let's reduce dependencies by assigning each team a feature". It did reduce dependencies, but we lost something more valuable: Time to market.
MVP for Feature A may require more effort than the MVP for Feature B. So Team B would be done with their MVP and start working on enhancing the Feature B while Team A were still not done on Feature A's MVP.
That lead to Team A taking 1 year to achieve their MVP while some other teams were way past their MVP and were into their "nice to have" stories.
That is where we introduced the notion of Milestones. Our milestones are a list of MVP Stories cross cutting features that we defined as User Journeys. Each team are still "owning" features, but we now follow the "everybody cross the finish line at the same time". So team B is not allowed to work on Milestone 2 Stories unless all Milestone 1 Stories from all teams are done. That means that Team B will do everything they can to help team A to reach the Milestone 1. That sounds counter intuitive, because it will probably take 3 or 4 times more effort for Team B to achieve same goal as Team A. But on a Time to Market perspective, it is awesome, because now we can go faster to market with a more limited set of features that comes together and only together unleash their full Business Value.
It's better to have a complete set of limited feature than an incomplete set of completed features.