Santhana Krishnan G

\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n

FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
How would you approach the situation to effectively help \"Waterfall Wix\" and the team embrace Agile principles? Consider at least one of the following aspects in your response:<\/p>\n\n\n\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Challenge:<\/strong><\/p>\n\n\n\n
How would you approach the situation to effectively help \"Waterfall Wix\" and the team embrace Agile principles? Consider at least one of the following aspects in your response:<\/p>\n\n\n\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
You are a new Agile Coach hired by a service company that has been struggling to transition from Waterfall to Agile methodologies. The Delivery Manager, \"Waterfall Wix,\" has been leading the team using traditional Waterfall practices for over 15 years. Despite training sessions and workshops on Agile, the team is still facing issues with over-planning, micromanagement, and a lack of flexibility. This has led to frustrated stakeholders, a demotivated team, and an increased risk of project failure.<\/p>\n\n\n\n
Challenge:<\/strong><\/p>\n\n\n\n
How would you approach the situation to effectively help \"Waterfall Wix\" and the team embrace Agile principles? Consider at least one of the following aspects in your response:<\/p>\n\n\n\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
Scenario:<\/strong><\/p>\n\n\n\n
You are a new Agile Coach hired by a service company that has been struggling to transition from Waterfall to Agile methodologies. The Delivery Manager, \"Waterfall Wix,\" has been leading the team using traditional Waterfall practices for over 15 years. Despite training sessions and workshops on Agile, the team is still facing issues with over-planning, micromanagement, and a lack of flexibility. This has led to frustrated stakeholders, a demotivated team, and an increased risk of project failure.<\/p>\n\n\n\n
Challenge:<\/strong><\/p>\n\n\n\n
How would you approach the situation to effectively help \"Waterfall Wix\" and the team embrace Agile principles? Consider at least one of the following aspects in your response:<\/p>\n\n\n\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
When I'm referring to agile scaling, I'm not talking about any particular Scaling Frameworks. When we help a few teams in an organization to implement agile practices in a pilot phase and extend those practices across the org, there are some unique challenges we face. Usually it is subjective influenced by the org's age, culture, nature of business, people, etc.

In this blog I'd like to study the use of Theory of Constraints (TOC) principles in scaling agile practices. The idea is to identify a structured way to eliminate bottlenecks to ensure value delivery and better efficiency. Also, to see whether TOC could address the scaling challenges like inter team dependencies, alignment of business objectives, process ineffectiveness, \u2026 and so on.

Courtesy: \"Theory of Constraint Institute<\/strong>\" (https:\/\/www.tocinstitute.org\/theory-of-constraints.html)

The Theory of Constraints is a process improvement methodology that emphasizes the importance of identifying the \"system constraint\" or bottleneck. By leveraging this constraint, organizations can achieve their financial goals while delivering on-time-in-full (OTIF) to customers, avoiding stock-outs in the supply chain, reducing lead time, etc.

The Core Idea \u2013 Every system has a limiting factor or constraint. Focusing improvement efforts to better utilize this constraint is normally the fastest and most effective way to improve profitability.<\/em>

Clearly this seem to address key challenges we would face while scaling agile practices.

Let us look into more details.

Step 1: Identify the Constraint<\/strong>

Find the biggest bottleneck in Agile transformation. Common Agile constraints include:
\u2022 Slow decision-making due to lack of leadership buy-in.
\u2022 Siloed teams that prevent collaboration.
\u2022 Lengthy approval processes delaying releases.
\u2022 Technical debt slowing down development speed.
\u2022 Overloaded teams with too many tasks in progress (WIP).

\ud83d\udca1 Example: A healthcare IT product team struggles with long testing cycles due to manual testing, delaying releases. Testing is the constraint.

Step 2: Exploit the Constraint (Maximize Efficiency Without Major Changes)<\/strong>

Before making drastic changes, optimize the existing process around the constraint.
\u2022 If the constraint is manual testing, prioritize automation for high-risk areas.
\u2022 If the constraint is delayed approvals, introduce lightweight governance models.
\u2022 If the constraint is slow development, reduce WIP limits to focus on high-priority work.

\ud83d\udca1 Example: The healthcare IT team prioritizes automating critical test cases first instead of automating everything at once.

Step 3: Subordinate Everything Else to the Constraint<\/strong>

Ensure other parts of the system do not create additional burden on the constraint.
\u2022 If testing is the constraint, ensure development teams write better unit tests to reduce testing effort.
\u2022 If decision-making is slow, streamline stakeholder involvement and define decision-making authority.
\u2022 If dependencies between teams cause delays, introduce Scrum of Scrums or cross-functional teams.

\ud83d\udca1 Example: The development team improves code quality and test coverage to reduce defects, making testing more efficient.

Step 4: Elevate the Constraint (Remove or Expand the Constraint)<\/strong>

If optimizing around the constraint is not enough, invest in solutions to eliminate it.
\u2022 Hire more testers or adopt AI-driven test automation to speed up testing.
\u2022 Redesign processes to decentralize decision-making and empower Agile teams.
\u2022 Reduce tech debt through refactoring and continuous integration.

\ud83d\udca1 Example: The healthcare IT team adopts CI\/CD pipelines and increases test automation coverage, reducing testing time by 60%.

Step 5: Repeat the Process (Continuous Improvement)<\/strong>

Once one constraint is resolved, find the next bottleneck and repeat the process.
\u2022 If testing is no longer a bottleneck, the next constraint could be delayed customer feedback.
\u2022 If slow approvals were fixed, the next challenge could be poor backlog prioritization.

\ud83d\udca1 Example: With faster testing, the team now identifies delayed user feedback as the next bottleneck and focuses on integrating real-time user analytics.

\u2705 Agile Transformation is an ongoing process\u2014TOC ensures continuous improvement.
\u2705 TOC helps focus on high-impact bottlenecks, rather than attempting to \u201cfix everything at once.\u201d
\u2705 Combining TOC with Agile frameworks like Scrum, Kanban, etc creates a more efficient and adaptable organization.
<\/p>\n","post_title":"Agile Scaling: Leveraging Theory of Constraints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"agile-scaling-leveraging-theory-of-constraints","to_ping":"","pinged":"","post_modified":"2025-03-15 21:25:05","post_modified_gmt":"2025-03-15 15:55:05","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=999767","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998352,"post_author":"28","post_date":"2024-07-19 14:41:10","post_date_gmt":"2024-07-19 09:11:10","post_content":"\n
Scenario:<\/strong><\/p>\n\n\n\n
You are a new Agile Coach hired by a service company that has been struggling to transition from Waterfall to Agile methodologies. The Delivery Manager, \"Waterfall Wix,\" has been leading the team using traditional Waterfall practices for over 15 years. Despite training sessions and workshops on Agile, the team is still facing issues with over-planning, micromanagement, and a lack of flexibility. This has led to frustrated stakeholders, a demotivated team, and an increased risk of project failure.<\/p>\n\n\n\n
Challenge:<\/strong><\/p>\n\n\n\n
How would you approach the situation to effectively help \"Waterfall Wix\" and the team embrace Agile principles? Consider at least one of the following aspects in your response:<\/p>\n\n\n\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

\n
<image courtesy: generative AI><\/em><\/p>\n\n\n\n
When I'm referring to agile scaling, I'm not talking about any particular Scaling Frameworks. When we help a few teams in an organization to implement agile practices in a pilot phase and extend those practices across the org, there are some unique challenges we face. Usually it is subjective influenced by the org's age, culture, nature of business, people, etc.

In this blog I'd like to study the use of Theory of Constraints (TOC) principles in scaling agile practices. The idea is to identify a structured way to eliminate bottlenecks to ensure value delivery and better efficiency. Also, to see whether TOC could address the scaling challenges like inter team dependencies, alignment of business objectives, process ineffectiveness, \u2026 and so on.

Courtesy: \"Theory of Constraint Institute<\/strong>\" (https:\/\/www.tocinstitute.org\/theory-of-constraints.html)

The Theory of Constraints is a process improvement methodology that emphasizes the importance of identifying the \"system constraint\" or bottleneck. By leveraging this constraint, organizations can achieve their financial goals while delivering on-time-in-full (OTIF) to customers, avoiding stock-outs in the supply chain, reducing lead time, etc.

The Core Idea \u2013 Every system has a limiting factor or constraint. Focusing improvement efforts to better utilize this constraint is normally the fastest and most effective way to improve profitability.<\/em>

Clearly this seem to address key challenges we would face while scaling agile practices.

Let us look into more details.

Step 1: Identify the Constraint<\/strong>

Find the biggest bottleneck in Agile transformation. Common Agile constraints include:
\u2022 Slow decision-making due to lack of leadership buy-in.
\u2022 Siloed teams that prevent collaboration.
\u2022 Lengthy approval processes delaying releases.
\u2022 Technical debt slowing down development speed.
\u2022 Overloaded teams with too many tasks in progress (WIP).

\ud83d\udca1 Example: A healthcare IT product team struggles with long testing cycles due to manual testing, delaying releases. Testing is the constraint.

Step 2: Exploit the Constraint (Maximize Efficiency Without Major Changes)<\/strong>

Before making drastic changes, optimize the existing process around the constraint.
\u2022 If the constraint is manual testing, prioritize automation for high-risk areas.
\u2022 If the constraint is delayed approvals, introduce lightweight governance models.
\u2022 If the constraint is slow development, reduce WIP limits to focus on high-priority work.

\ud83d\udca1 Example: The healthcare IT team prioritizes automating critical test cases first instead of automating everything at once.

Step 3: Subordinate Everything Else to the Constraint<\/strong>

Ensure other parts of the system do not create additional burden on the constraint.
\u2022 If testing is the constraint, ensure development teams write better unit tests to reduce testing effort.
\u2022 If decision-making is slow, streamline stakeholder involvement and define decision-making authority.
\u2022 If dependencies between teams cause delays, introduce Scrum of Scrums or cross-functional teams.

\ud83d\udca1 Example: The development team improves code quality and test coverage to reduce defects, making testing more efficient.

Step 4: Elevate the Constraint (Remove or Expand the Constraint)<\/strong>

If optimizing around the constraint is not enough, invest in solutions to eliminate it.
\u2022 Hire more testers or adopt AI-driven test automation to speed up testing.
\u2022 Redesign processes to decentralize decision-making and empower Agile teams.
\u2022 Reduce tech debt through refactoring and continuous integration.

\ud83d\udca1 Example: The healthcare IT team adopts CI\/CD pipelines and increases test automation coverage, reducing testing time by 60%.

Step 5: Repeat the Process (Continuous Improvement)<\/strong>

Once one constraint is resolved, find the next bottleneck and repeat the process.
\u2022 If testing is no longer a bottleneck, the next constraint could be delayed customer feedback.
\u2022 If slow approvals were fixed, the next challenge could be poor backlog prioritization.

\ud83d\udca1 Example: With faster testing, the team now identifies delayed user feedback as the next bottleneck and focuses on integrating real-time user analytics.

\u2705 Agile Transformation is an ongoing process\u2014TOC ensures continuous improvement.
\u2705 TOC helps focus on high-impact bottlenecks, rather than attempting to \u201cfix everything at once.\u201d
\u2705 Combining TOC with Agile frameworks like Scrum, Kanban, etc creates a more efficient and adaptable organization.
<\/p>\n","post_title":"Agile Scaling: Leveraging Theory of Constraints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"agile-scaling-leveraging-theory-of-constraints","to_ping":"","pinged":"","post_modified":"2025-03-15 21:25:05","post_modified_gmt":"2025-03-15 15:55:05","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=999767","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998352,"post_author":"28","post_date":"2024-07-19 14:41:10","post_date_gmt":"2024-07-19 09:11:10","post_content":"\n
Scenario:<\/strong><\/p>\n\n\n\n
You are a new Agile Coach hired by a service company that has been struggling to transition from Waterfall to Agile methodologies. The Delivery Manager, \"Waterfall Wix,\" has been leading the team using traditional Waterfall practices for over 15 years. Despite training sessions and workshops on Agile, the team is still facing issues with over-planning, micromanagement, and a lack of flexibility. This has led to frustrated stakeholders, a demotivated team, and an increased risk of project failure.<\/p>\n\n\n\n
Challenge:<\/strong><\/p>\n\n\n\n
How would you approach the situation to effectively help \"Waterfall Wix\" and the team embrace Agile principles? Consider at least one of the following aspects in your response:<\/p>\n\n\n\n
\n
Building Trust:<\/strong> How would you establish trust and rapport with \"Waterfall Wix\" to understand his\/ her concerns and resistance to Agile?<\/li>\n\n\n\n
Training and Coaching:<\/strong> What specific training and coaching strategies would you employ to help Wix and the team transition smoothly?<\/li>\n\n\n\n
Incremental Changes:<\/strong> How would you introduce incremental changes to minimize disruption and demonstrate the benefits of Agile practices?<\/li>\n\n\n\n
Stakeholder Communication:<\/strong> What steps would you take to improve communication and transparency with stakeholders to ensure their buy-in and satisfaction?<\/li>\n\n\n\n
Empowering the Team:<\/strong> How would you empower the team to take ownership of their work and foster a culture of collaboration and continuous improvement?<\/li>\n<\/ol>\n\n\n\n
Provide a detailed plan outlining your approach and justify your strategies based on the principles discussed in the blog.<\/p>\n","post_title":"CHOW","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"chow-7","to_ping":"","pinged":"","post_modified":"2024-07-19 14:52:38","post_modified_gmt":"2024-07-19 09:22:38","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998352","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":998348,"post_author":"28","post_date":"2024-07-19 14:28:53","post_date_gmt":"2024-07-19 08:58:53","post_content":"\n
Introduction:<\/strong> From Wikipedia, the free encyclopedia ( https:\/\/en.wikipedia.org\/wiki\/Anti-pattern<\/a>): \"An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.\"<\/p>\n\n\n\n
Personas are fictional characters<\/strong> representing commonalities of a representative sample of a system. They draw a comprehensive picture<\/strong> of the users.<\/p>\n\n\n\n
Let us look at one persona 'Waterfall Wix<\/strong>' popular in Software Service Companies that are in their early stages of Agile Transformation.<\/p>\n\n\n\n
Persona: Waterfall Wix<\/strong><\/p>\n\n\n\n
\n
Role:<\/strong> Delivery Manager in a Software Service Company<\/li>\n\n\n\n
Background:<\/strong>\n
\n
Experience:<\/strong> 15+ years in a reputed software services company <\/li>\n\n\n\n
Education:<\/strong> PMP Certified, MBA from a premier institute<\/li>\n<\/ul>\n<\/li>\n\n\n\n
Traits:<\/strong>\n
\n
Rigidity:<\/strong> Clings to the waterfall methodology's linear, phase-based approach, viewing change as disruptive and delays as inevitable.<\/li>\n\n\n\n
Over Planning:<\/strong> Insists on comprehensive project plans and detailed estimates before starting development.<\/li>\n\n\n\n
Micromanagement and Meeting Overkill:<\/strong> Runs multiple status meetings, overwhelming the team.<\/li>\n\n\n\n
Fear of Failure:<\/strong> Prioritizes sticking to the plan over flexibility, hesitant to experiment or adapt based on new information.<\/li>\n\n\n\n
\"I had been there, done that\":<\/strong> Prefers familiar methods over new ones due to past experiences.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Quotes:<\/strong><\/p>\n\n\n\n
\n
\u201cWe need to have everything planned out before we start.\u201d<\/li>\n\n\n\n
\u201cI need daily updates on what everyone is doing.\u201d<\/li>\n\n\n\n
\u201cWhy do we need another review meeting? We already know what needs to be done.\u201d<\/li>\n<\/ul>\n\n\n\n
Impact on Agile Implementation:<\/strong><\/p>\n\n\n\n
\n
Frustrated Stakeholders:<\/strong> Lack of communication and inflexible delivery schedules leave stakeholders in the dark and dissatisfied.<\/li>\n\n\n\n
Demotivated Team:<\/strong> Micromanagement and a rigid environment stifle creativity and team morale, limiting the ability to innovate and adapt to changes.<\/li>\n\n\n\n
Increased Risk:<\/strong> The lack of flexibility increases the risk of failure to deliver value incrementally.<\/li>\n<\/ul>\n\n\n\n
How to Avoid Being a 'Waterfall Wix':<\/strong><\/p>\n\n\n\n
\n
Embrace Change:<\/strong> Through training and coaching, help Wix understand the importance of adapting to new information and user feedback. Encourage openness to iterating and improving continuously.<\/li>\n\n\n\n
Incremental Transition:<\/strong> Gradually transition from Waterfall to Agile, allowing Wix to experience the benefits firsthand.<\/li>\n\n\n\n
Empower the Team:<\/strong> Encourage Wix to empower the team and trust their ability to self-organize and deliver value.<\/li>\n\n\n\n
Focus on Value and Outcomes:<\/strong> Shift the focus from rigid plans and documentation to delivering customer value and incremental outcomes.<\/li>\n\n\n\n
Communication is Key:<\/strong> Keep stakeholders, both internal and external, informed and involved throughout the development process.<\/li>\n<\/ul>\n\n\n\n
Conclusion:<\/strong> By understanding and addressing the traits of \"Waterfall Wix,\" teams can navigate the challenges of Agile implementation more effectively. The strategies provided offer practical steps to foster a successful and adaptive Agile environment, ensuring continuous improvement and value delivery.<\/p>\n","post_title":"\"Waterfall Wix:\u00a0The Agile Implementation Roadblock\"","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"waterfall-wix-the-agile-implementation-roadblock","to_ping":"","pinged":"","post_modified":"2024-07-19 14:36:32","post_modified_gmt":"2024-07-19 09:06:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.pm-powerconsulting.com\/?p=998348","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20662,"post_author":"28","post_date":"2023-04-12 15:18:49","post_date_gmt":"2023-04-12 09:48:49","post_content":"\n
Scoping is always an important and challenging activity in software\ndevelopment. Irrespective of whether we are scoping a product's particular\nversion or project's specific release, we could use a set of steps to arrive at\nan MVP, Minimum Viable Product, that has a clear value definition, user\nvalidation and better chance of success. In my experience, I've found the\nfollowing set to be very effective:<\/p>\n\n\n\n
Elevator Pitch<\/strong> <\/li><\/ul>\n\n\n\n
One of a simple and effective format to define our product vision\nis:<\/p>\n\n\n\n
\"For <\/strong><target customer \/ group><\/p>\n\n\n\n
Who <\/strong> <needs a solution or has a problem><\/p>\n\n\n\n
The <\/strong><our product \/ service> <\/p>\n\n\n\n
Is a <\/strong><key feature or primary set of\nprocesses><\/p>\n\n\n\n
That <\/strong><what our product would do><\/p>\n\n\n\n
Unlike <\/strong><existing products \/ services><\/p>\n\n\n\n
<our Product \/\nservice> <\/strong><how does it solves the need \/\nproblem>\"<\/p>\n\n\n\n
It is called an Elevator Pitch as this can be\neasily explained to a potential client or to a prospective employee with in a\nfew minutes. It should be interesting, memorable, and\nsuccinct. It also need to explain what makes the product unique or stand out.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-elevator-pitch\/\n<\/div><\/figure>\n\n\n\n
User Persona with their pains and gains<\/strong><\/li><\/ul>\n\n\n\n
Hypothetical representations of Actual or Potential\ncustomers are described by visual stories called Personas. They draw a\ncomprehensive picture of the users of our system. The details include, what our\nusers want to accomplish, what skills they may or may not have and what are\ntheir needs, wants and priorities. <\/p>\n\n\n\n
We can arrive at personas by brainstorming, user\nresearch, customer interview, secondary research of industry data, etc. It is a\ngood practice to arrive at more than one user persona representing each key\ncustomer segment so that we could develop features to meet their expectations.<\/p>\n\n\n\n
After identifying our personas, we have to detail out\ntheir goals, motivations, pain points and gains. Pains are their challenges and\nthe gains are benefits if and when they use our system.<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-1-user-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-2-3-building-hypotheses\/\n<\/div><\/figure>\n\n\n\n
User Journey map and features<\/strong><\/li><\/ul>\n\n\n\n
User Journey is a visual representation that\nillustrates user' flow (series of steps a.k.a. activities) within a product or\nservice, their interactions with the system and the overall experience for a\nparticular goal. The user journey could be created by mapping all user touch\npoints, the mode of interaction and expected outcome for each goal. We have to create at least one user journey\nfor each user persona. <\/p>\n\n\n\n
First, we capture the current state as a journey. Then\nusing the user persona's goals, motivations, wants and expectations, we capture\nthe future state of the journey. <\/p>\n\n\n\n
With a few variations, these user journeys are some\ntimes called as Experience Maps or User Journey Maps. <\/p>\n\n\n\n
Now, we have user persona --> goals -->\nactivities. <\/p>\n\n\n\n
Next we have to arrive at tasks for these activities.\nThe tasks could be sliced further to arrive at \nUser Stories or Use Cases or Granular Requirement Specification as the\nneed be.<\/p>\n\n\n\n
Now, we have a set of requirement statements (features)<\/p>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-user-journey-map\/\n<\/div><\/figure>\n\n\n\n
FAB<\/strong> (Feature-Advantage-Benefit)<\/li><\/ul>\n\n\n\n
FAB helps us define the advantages and benefits of the\nfeatures identified. FAB could be used as one of the parameters in prioritizing\nthe features for MVP. Also, we could articulate the feature and their benefits\nbetter to our customer. <\/p>\n\n\n\n
\n Feature\n <\/td> \n Advantage\n <\/td> \n Benefit\n <\/td><\/tr>
\n E.g. Stainless steel as material for knife\n <\/td> \n Won't easily rust\n <\/td> \n Durability\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\n<\/div><\/figure>\n\n\n\n
Prioritized backlog (MVP)<\/strong><\/li><\/ul>\n\n\n\n
MVP expands to Minimum Viable Product. It is a set of\nprioritized features just enough to cover the identified primary needs,\nexpectations of the targeted customer segment.<\/p>\n\n\n\n
The prioritized features from Step 4 are estimated.\nWith priority based on benefit and estimates, we will be able to arrive at MVP\nand its release plan.<\/p>\n\n\n\n
\nhttp:\/\/pm-powerconsulting.com\/blog\/sizing\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\n<\/div><\/figure>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\n<\/div><\/figure>\n","post_title":"5 step \"product visioning\" to scope","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"5-step-product-visioning-to-scope","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/product-visioning-3-3-prioritization-backlog\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-fab-feature-advantage-benefit\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-5-guess-the-timeline-part-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/product-visioning-identifying-right-target-persona\/","post_modified":"2024-03-24 16:43:22","post_modified_gmt":"2024-03-24 16:43:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20662","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20044,"post_author":"28","post_date":"2022-06-12 22:25:46","post_date_gmt":"2022-06-12 16:55:46","post_content":"\n
For an adaptive leadership to succeed in a chaordic organization, one of the key factors is mutual trust. Could you please highlight top two things from your list that helps develop trusting culture in an organization?\u00a0<\/p>\n\n\n\n
<\/p>\n\n\n\n
CHOW Solution:<\/p>\n\n\n\n
There are so many practices to be set and followed consistently over a period to build trust and sustain it. As a start, I like the idea of Laura Thomson\u2019s excellent talk on Minimum Viable Bureaucracy as written by Doug Belshaw (https:\/\/dougbelshaw.com\/blog\/tag\/chaordic-systems\/<\/a>)<\/p>\n\n\n\n
Begin by trusting others<\/li>
Be trustworthy<\/li><\/ol>\n","post_title":"CHOW #298 - Adaptive Leadership","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-6","to_ping":"","pinged":"","post_modified":"2024-01-29 12:44:35","post_modified_gmt":"2024-01-29 12:44:35","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20044","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20038,"post_author":"28","post_date":"2022-06-12 22:17:09","post_date_gmt":"2022-06-12 16:47:09","post_content":"\n
It is not new that developments in one field influences the innovations in another popularly known as 'The Medici Effect' (Ref 5) explained by Frans Johansson in his book 'The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures'.<\/em><\/p>\n\n\n\n
In the last couple of decades, better understanding of non-linear characteristics of nature such as emergence, chaos, collective intelligence, by scientists, started influencing organizational management space also. Instead of looking at static processes and fixed hierarchical structures, organizations embraced dynamic systems, flexible pods and adaptive leadership. <\/p>\n\n\n\n
Dee Hock, the founder and the former CEO of Visa, coined a term 'Chaord' by combining 'Chaos' and 'Order'.  <\/p>\n\n\n\n
In his own words:<\/p>\n\n\n\n
\u201cBy chaord, I mean any self-organizing, self-governing, adaptive, nonlinear, complex organism, organization, community or system, whether physical, biological or social, the behavior of which harmoniously blends characteristics of both chaos and order. Loosely translated to business, it can be thought of as an organization that harmoniously blends characteristics of competition and cooperation; or from the perspective of education, an organization that seamlessly blends theoretical and experiential learning.\" (Ref: 1)<\/p>\n\n\n\n
An organization in chaos, shall move towards better co-ordination than control, accepting variability than forcing uniformity, encouraging effectiveness over emphasizing efficiency to being a chaordic organization. <\/p>\n\n\n\n
This is more relevant to the organizations now than ever. The nature of challenges organizations faced in the last few years and the pace at which things changed caused a lot of turbulence in their structures and operations. The ripples rode through the breadth and depth of the organizations and their impact was felt across the functions. Even the organizations that adopted agile were not spared. <\/p>\n\n\n\n
Agile organizations are familiar with adaptive leadership. Most of them would be at various stages of its implementation. Let us look at a specific chaordic flavour to better adaptive leadership abilities.<\/p>\n\n\n\n
Chaordic leadership involves four main responsibilities\u00a0[Ref: 4], which are<\/p>\n\n\n\n
manage self 50% of the time<\/li>
manage those with authority over us 25% of the time<\/li>
manage your peers 20% of the time and<\/li>
manage those we are responsible for 5% of the time<\/li><\/ol>\n\n\n\n
In an agile organization, every individual is empowered to do right things and do them right. When they use the above guidelines, the emerging result at org level could be bigger than the sum of its parts. <\/p>\n\n\n\n
The following benefits were observed in chaordic organizations:<\/p>\n\n\n\n
Increased motivation: as individuals could influence their objectives, methods and processes<\/li>
Increased self-organization as they are responsible for the progress<\/li>
Blurred hierarchies<\/li>
Decreased pressure to succeed<\/li>
Courage to experiment as fail fast is acceptable and encouraged<\/li>
Increased innovation due to the last two points<\/li><\/ul>\n\n\n\n
A few key areas \/ symptoms to watch out for:<\/p>\n\n\n\n
There may not be a visible structure, by design. This may not be comfortable for the people who are used to static structures. They shall be provided with reasonable support and coaching.<\/li>
Rules may not sustain as they are meant to be broken. Hence, finding alternate messaging and more cooperative checks and balances might help.<\/li>
Some times, large scale, strategic decisions could take longer than what used to be.\u00a0<\/li><\/ul>\n\n\n\n
References and further reading:<\/p>\n\n\n\n
https:\/\/www.meadowlark.co\/the_art_of_chaordic_leadership_hock.pdf<\/a><\/li>
https:\/\/patimes.org\/leading-organization-chaos\/<\/a><\/li>
https:\/\/ase.in.tum.de\/lehrstuhl_1\/research\/paper\/krusche2017chaordic.pdf<\/a><\/li>
http:\/\/www.businessdictionary.com\/definition\/chaordic-leadership.html<\/a><\/li>
The Medici Effect: Breakthrough Insights at the Intersection of Ideas, Concepts, and Cultures by Frans Johansson<\/em><\/li><\/ol>\n\n\n\n\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n\n\n\n
<\/p>\n","post_title":"Chaordic Organizations - in present context","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chaordic-organizations-in-present-context","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:20","post_modified_gmt":"2024-03-24 07:46:20","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20038","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19324,"post_author":"28","post_date":"2021-11-01 13:04:22","post_date_gmt":"2021-11-01 07:34:22","post_content":"\n
What was your agile transformation experience of reasonably large-sized teams (50+ people)? To be specific, what are your observations of the team's productivity in shorter-term, say 3 to 4 months? <\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
For any software development team, transitioning into agile brings in surprises, sometimes pleasant and at times not so. <\/p>\n\n\n\n
The teams usually focus on the softer aspects like mindset, behavior, communication, mutual trust, transparency, and so on. And this is the time-tested success recipe. <\/p>\n\n\n\n
Having said that, the productivity parameters are important too. Especially for the client-facing teams, for teams having critical deliverable timelines, the challenges are manifold. They have to embrace change without missing the commitments. <\/p>\n\n\n\n
In my experience, and from what I hear in my colleagues' circle, there would be an initial dip in the productivity parameters before they climb up. Oftentimes, the graph might look like a hockey stick. So, we factor in that dip in our transition plans. This happens irrespective of the team size. More so with larger-sized teams. <\/p>\n","post_title":"CHOW #270 - Shorter Term Productivity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-5","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:25","post_modified_gmt":"2024-03-24 07:46:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19324","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$ Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18531,"post_author":"28","post_date":"2021-03-26 20:32:40","post_date_gmt":"2021-03-26 15:02:40","post_content":"\n
Do you think tasking would help reduce the creation of knowledge silos? <\/p>\n\n\n\n
Would it help developers rotate stories\/tasks easily?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
Tasking done effectively, would help share the knowledge within the team. I've worked with teams that tasked their stories during sprint planning. Even though the sprint planning meeting took 2-3 hours for a 5-6 member team, it was very useful in knowledge sharing:<\/p>\n\n\n\n
\n
Every team member contributes to every story's approach.<\/li>\n\n\n\n
Design decisions are discussed.<\/li>\n\n\n\n
Tasks include automation and testing. That irons out the testing approach for every story.<\/li>\n\n\n\n
Dependencies are discussed in detail.<\/li>\n\n\n\n
Risks and alternate approaches are arrived at.<\/li>\n<\/ul>\n\n\n\n
During the sprint, the familiarity increases the confidence and hence team members are comfortable picking any task. Story swarming becomes very effective. <\/p>\n\n\n\n
Also, if the teams practice pair programing, frequent pair rotation is easier. <\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #241 Will tasking reduce knowledge silos?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-4","to_ping":"","pinged":"","post_modified":"2024-01-29 12:45:43","post_modified_gmt":"2024-01-29 12:45:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18531","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18520,"post_author":"28","post_date":"2021-03-26 20:29:45","post_date_gmt":"2021-03-26 14:59:45","post_content":"\n
All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions.\u00a0<\/p>\n\n\n\n
I'm going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.<\/p>\n\n\n\n
When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.<\/p>\n\n\n\n
The following chart is an actual case from one of the teams that had started embracing agile recently. <\/p>\n\n\n\n
This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
One of the approaches I tried with reasonable success is to task\/sub-task the stories. The sub-tasks are granular:<\/p>\n\n\n\n
Tasking: Guidelines<\/p>\n\n\n\n
Granular: could be done in 1 day or 2<\/li>
Technical \/ Horizontal ...<\/li>
Clear Estimates in Effort Hours<\/li>
Always look ahead: how much more time necessary (NOT how much time spent)<\/li><\/ul>\n\n\n\n
Usually, I'd encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story\/task, in any eventuality, is easier. <\/p>\n\n\n\n
Tasking: Benefits<\/p>\n\n\n\n
Increases transparency<\/li>
Improves our ability to respond (as we get quicker feedback)<\/li>
Possible to distribute Test Effort<\/li><\/ul>\n\n\n\n
Test Early (at task level): Fail Fast<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached.\u00a0<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Tasking: Challenges<\/p>\n\n\n\n
There may be an argument that the effort estimate in hours is not the agile way<\/li>
Tasking is micro-managing<\/li><\/ul>\n\n\n\n
My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. <\/p>\n\n\n\n
Reference:<\/p>\n\n\n\n
https:\/\/www.mountaingoatsoftware.com\/blog\/capacity-driven-sprint-planning<\/a><\/li><\/ul>\n\n\n\n
\nhttps:\/\/pm-powerconsulting.com\/experts\/santhana-krishnan\/\n<\/div><\/figure>\n","post_title":"Sprint Burndown useful?!","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"sprint-burndown-useful","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:33","post_modified_gmt":"2024-03-24 07:46:33","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18520","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 4 1 2 … 4 Next

Santhana Krishnan G

Agile

Agile Scaling: Leveraging Theory of Constraints

by Santhana Krishnan G
March 15, 2025

Agile

CHOW

by Santhana Krishnan G
July 19, 2024

Agile

“Waterfall Wix: The Agile Implementation Roadblock”

by Santhana Krishnan G
July 19, 2024

Product Management

5 step “product visioning” to scope

by Santhana Krishnan G
April 12, 2023

Chow

CHOW #298 – Adaptive Leadership

by Santhana Krishnan G
June 12, 2022

Agile

Chaordic Organizations – in present context

by Santhana Krishnan G
June 12, 2022

Agile

CHOW #270 – Shorter Term Productivity

by Santhana Krishnan G
November 1, 2021

Agile

To or Not-To Agile – An Experience Report

by Santhana Krishnan G
November 1, 2021

Chow

CHOW #241 Will tasking reduce knowledge silos?

by Santhana Krishnan G
March 26, 2021

Agile

Sprint Burndown useful?!

by Santhana Krishnan G
March 26, 2021

Page 1 of 4 1 2 … 4 Next

PM Power Consulting helps organizations achieve agility in design and delivery of software and services.

Our Offerings

Execution Excellence

Leadership Development

Organizational Excellence

About Us

Blog

Podcasts

Contact

Experts

© 2025

PM Power Consulting

Linkedin Facebook Youtube

Search for:

Agile Scaling: Leveraging Theory of Constraints

CHOW

“Waterfall Wix: The Agile Implementation Roadblock”

5 step “product visioning” to scope

CHOW #298 – Adaptive Leadership

Chaordic Organizations – in present context

CHOW #270 – Shorter Term Productivity

To or Not-To Agile – An Experience Report

CHOW #241 Will tasking reduce knowledge silos?

Sprint Burndown useful?!

PM Power Consulting helps organizations achieve agility in design and delivery of software and services.

Our Offerings

Execution Excellence

Leadership Development

Organizational Excellence

Large-Scale Transformation To Agile

Starting & Scaling Agile Transformation

Fully Automated Analytics Platform

ehancing project management capabilities

Enterprise Wide Digital Transformation

Books

Videos

SPS Podcast

FSL Podcast

Blogs

Challenge Of the Week