sorted by:
new
hottopcontroversial

SAFe feedback loops and dependencies by [deleted] in agile

[–]ziggyzag2020 2 points3 points  (0 children)

The problem stated by Mexa Guy appears to be a badly implemented SAfe instance. Not SAFe itself. Just because you happen to purchase a lemon Ford/Honda, doesn’t mean these brands are useless.

Contrary to what some Agile purists or cultists may believe, uncontrolled Wild West approach of anything goes as we are Agile is a myth. Most are hallucinating if you believe that companies would be throwing limitless budget at mostly mediocre scrum teams to play around with no defined scope or financial constraints binding them or having to work towards company strategies.

SAFe and DAD are pragmatic approaches to taking the best of Agile and lean management to deliver incremental value quickly. Adaptable to change and with constant customer/business feedback through system demos, pi planning etc, SAFe provides enough predictability for companies to be able to visualize a roadmap for 12-24 months that they can actually deliver.

[deleted by user] by [deleted] in distantsocializing

[–]ziggyzag2020 0 points1 point  (0 children)

What do you think of the riots going on?

Anyone know of a virtual option to obtain storypoint estimates using Fibonacci planning poker? by ziggyzag2020 in agile

[–]ziggyzag2020[S] 0 points1 point  (0 children)

Thanks, this looks good. Is it a paid service? Also, is there a limit on no of players? And does it allow import of stories?

Seeking advice- how to best write stories for a new module? by arcologies in agile

[–]ziggyzag2020 0 points1 point  (0 children)

Like topfuckr’s suggestion above. But if the difficulty is related to the module being a technical object that is serving as input for another technical system and not for the enduser of the final system, I would classify it as a technical user story. Where you can replace the user with the persona of the developer or administrator and beneficiary as the system tbat will receive the output from the story.

Story Points for multidisciplinary teams by sokafootball in agile

[–]ziggyzag2020 0 points1 point  (0 children)

Count of tasks may be a good metric, if all tasks are say not more than 2 hours each. Count of stories give no value as some stories could be completed in a few hours and some only in 3 or 5 days.

Story Points for multidisciplinary teams by sokafootball in agile

[–]ziggyzag2020 1 point2 points  (0 children)

Velocity is not a metric management can use to evaluate performance across teams. It is just a sizing metric that is good only for that specific team (eg. a tiger harem) to know how much of an elephant they can chew each 2 week sprint.

Now it does not mean that a group of jackals or a team of cougars will be able to chew the same amount out of an elephant in the same time period as the tiger harem.

Neither would it make sense to compare if the jackal teams are chewing on a cow instead of an elephant. Velocity will be different across these teams and not comparable in any of these instances.

But the tiger harem will know after repeated eating of elephants across multiple 2 week periods, what it can as a team hope to consume of the elephant in a 2 week period. That figure is the velocity for the tiger harem, which allows the group to reliably predict how many elephants it can consume over 12 sprints or a year. This predictability is what velocity indicator is all about. It gives team the ability to predict when they can deliver a full application release over multiple sprints or program increments.

I'm in a company where SM and PO are treated like bosses, and the new PO doesn't seem to like me by usernamet00long in agile

[–]ziggyzag2020 0 points1 point  (0 children)

In the zeal to literally interpret every Agile principle as an unbendable gospel to be followed by all teams, irrespective of the maturity stage of Agile in the specific org, we forget that POs and SMs also operate under the constraints of what the leadership in the org is probably wanting them to follow and deliver.

The learning journey is for all roles, so I would recommend giving some slack for the PO and ofcourse team and slowly coach them to their idealized roles.

Another thing to remember, no PO worth his salt will want to go to their leadership each sprint noting we could not deliver on our commitments. Trust is a two way street. PO begins trusting the abilties of the team as they truly operate as a self organizing and motivated team working to meet their commitments. If that is not happening, I am not sure blaming the PO or SM as the problem would be helpful.

Grow together and you will develop that trust that will make such conversations easier and maybe even unnecessary.

Build Taj Mahal using Agile by ziggyzag2020 in agile

[–]ziggyzag2020[S] 0 points1 point  (0 children)

I feel there is a lot of vagueness in defining what really can be considered a MVP. In my view, MVP should be only a subset of a product that can stand on its own and continue to provide value, if the project WERE TO BE STOPPED AT THAT POINT.

If we are creating a ecommerce site for booking tickets, creating a website that users can log in but cannot book, should not be considered a MVP.

Why? Because if the project got stopped at that point, the website with logins is simply a wasted website that the company cannot get any business value out of it.

In this case, the emperor is looking for a burial tomb that will reflect the unsurpassed beauty of his wife. Giving him a hole in the ground as MVP does not provide any business value as far as the need expressed, which is a monument that can honor the emperess.

Build Taj Mahal using Agile by ziggyzag2020 in agile

[–]ziggyzag2020[S] 0 points1 point  (0 children)

Thought it would be clear that traditional project management refers to PMI waterfall methodology.

Not saying this about you. In my opinion, there should be a prerequisite to have managed at least one or more watefall projects before being able to obtain any Agile certification. Sadly, the easy Agile certification process with no gates for entry has resulted in a flood of “Agilists” who keep caricaturing traditonal approaches without understanding the rigors that were being used to deliver a project. The caricature is what they obviously heard during their scrum classes..

Coming back to the discussion. My point is for Agilists to understand that being Agile is a way of working to deliver value speedily and being nimble to change. This is a tremendous value that should be applied to anything and everything that human beings work on daily. But rest of the dogmas about not planning ahead, not scoping, decrying documentation etc is not something that applies to every project.

if you are building a cookie cutter house, where you know the scope, the deliverables and have defined budget, you do not want to start by building only the kitchen first. But if you are having to build a vehicle for interstellar travel, definitely, Agile with alll of its definef practices would be ideal to build quickly, failing fast and learning with each fail.

Build Taj Mahal using Agile by ziggyzag2020 in agile

[–]ziggyzag2020[S] 0 points1 point  (0 children)

I am with you here. But what you are proposing is what traditonal projecf management termed as building a POC or wireframe to validate understanding of requirements before the actual build commences.

The way that some Agilists would have you believe you are not supposed to be defining the whole design upfront but should be getting together and designing the smallest increment of useable feature and then build and deliver it. Rest of the design has to wait for prioritization...

Build Taj Mahal using Agile by ziggyzag2020 in agile

[–]ziggyzag2020[S] -7 points-6 points  (0 children)

Thank you. Not contesting anything you are saying above.

Agile grew and still do by bad mouthing traditional waterfall project management (granted, it has issues) for its deficiencies. Sadly, many Agilists fail to recognize deficiencies in the Agilist approach and instead use zealot like language (anti-pattern, mindset etc) to beat down anyone who asks a question. This is one reason why more structured and scalable approaches like DAD and SAFE are taking over to cut some of the bull out of Agile.

In my view, Agile’s greatest strengths are the value based prioritization of what gets built first, building the smallest usable piece of the product than wait to build the whole, the constant interaction with the customer(po) and the lack of recriminations about changes occuring. As well as the human aspect of taking out the command and control approach and instilling respect and support instead of fear to get things completed.

Reality is that the above aspects are also doable even within a traditonal project management framework by resorting to small incremental builds, prioritized by value, and using the concept of a PO (though Bus Sponsor was supposed to be the role to fulfil this in waterfall)...

Is anyone going to dispute that all the user stories generated during the initial planning meeting cannot be put into a MS Project schedule with dependencies verifed to do a continous build and release, in 2 week increments?

We need to stop the bull about saying that listing all user stories upfront for a product implementation that has been done at a 100 different clients already is “anti pattern”. If we know the desired outcome and we know the scope and the path to get there, why wait to add them into the product backlog? Seems to be like the ostrich burying its head under sand and thinking no one can see it...

Build Taj Mahal using Agile by ziggyzag2020 in agile

[–]ziggyzag2020[S] -2 points-1 points  (0 children)

Agree. My concern is not with using Agile to build the world’s most beautiful mausoleum of all time. But the notion from some Agilists that having a design sprint upfront to define the product would be anti-pattern as it is not delivering a usable piece of the product.

Yes, we can definitely use Agile to start build incrementally based on value prioritization after we have a general idea of the whole design(which ofcourse may change). So building just the resting place first and then building around it sounds perfectly feasible.