#How To #Apply the #ScopeMaster® Across #Agile #Sprints

The article explains the gaps in applicability of ScrumMaster to individual Agile Spriner and describes the operational method that close these gaps and dramatically improved outcomes of ScopeMaster in application across increasing number of project sprints.

“#Lean #Architecture”: is it for real?

Published on January 7, 2019 I’ve just checked Google for the term “Lean Architecture” and found several links, all of which lead to a quite ambiguous situation. Not earlier than last year, Chris Shayan published an article “Lean Architecture” in DZone. He said, ”The concept or architecture remains a staple in descriptions of various forms […]

Beware: Sprint Abuses SOA in Microservices

Published on December 22, 2018 For the last couple of years, people were debating whether Microservices realise SOA. With my experience in Services of 22 years, I can confirm that Microservices do realise SOA at a “teenager” maturity level, while Web Services and REST were at the kindergarten SOA maturity level. How am I count […]

In the Mind of Experienced Architect Learning SAFe

Published on April 8, 2018 Let’s imagine an IT architect with more than 10 years of experience at project, programme and enterprise level. This person starts working on each new task with two questions: “what is it?” and “why is this needed/important?”. The architect appreciates new technologies when they deliver what they promise and are […]

When Agile Steps on Its Own Tail: an observation from tranches

Published on January 15, 2017 Every profession is associated with certain objectives and attributes, which allow to distinguish it from another one. The same understanding exist or should exist in IT. When we run a project in an Agile Scrum methodology, we usually recognise three roles: Project/Product Owner, Scrum Master and a Team. It is […]

‘How-to’ for MoSCoW Method: Resolving Fundamental Problems

Published on December 8, 2018 The MoSCoW method exists for many years already and the common opinion is that this method is for prioritising requirements, business or technical. It is used for achieving a shared understanding (Problem #1) with stakeholders on the priority they (Problem # 2) identify for each requirement. Apparently, MoSCoW is only […]