Skip to content

Commit a7825e7

Browse files
committed
1 parent b5d7c59 commit a7825e7

File tree

2 files changed

+2
-2
lines changed

2 files changed

+2
-2
lines changed

_posts/2014-10-22-agile-v-lean.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ For example, an analysis I performed a while ago on a series of project releases
3434

3535
The top image is a [Cumulative Flow Diagram](http://www.slideshare.net/yyeret/explaining-cumulative-flow-diagrams-cfd) (CFD) for a number of releases into production of a product. Each band shows the user stories that were queued or in in-progress at that time. The large steps are where the process was outside of the project team's direct control. The thinner red stripe was where the team were working in an incremental way to develop and test the software within sprints. The green band after the red stripe shows the software "sitting on the shelf" for the next phase.
3636

37-
Restrospectives would centre on the "red stripe". Blockers, knowledge transfer, skills, planning, estimates, etc, etc.
37+
Retrospectives would centre on the "red stripe". Blockers, knowledge transfer, skills, planning, estimates, etc, etc.
3838

3939
### Wider Improvement
4040

_posts/2018-10-22-ok-not-to-be-agile.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ There are a couple of project types to discuss here:
2929

3030
#### Integration projects
3131

32-
This is an area I've been working in for the last couple of years. Agile doesn't really provide benefit here for very interesting reasons - the development phase is really tiny, basically a few minutes linking bits of "pipe" together if you're using a product such as [Mulesoft][mulesoft], [IBM API Connect][apiconnect], or even Camel (especially the exciting new [Camel K][camelk]). With these platforms, it can take significantly longer to write your Jira task than to actually complete the development phase!
32+
This is an area I've been working in for the last couple of years. Agile doesn't really provide benefit here for very interesting reasons - the development phase is really tiny, basically a few minutes linking bits of "pipe" together if you're using a product such as [MuleSoft][mulesoft], [IBM API Connect][apiconnect], or even Camel (especially the exciting new [Camel K][camelk]). With these platforms, it can take significantly longer to write your Jira task than to actually complete the development phase!
3333

3434
Secondly, there is the fact that an integration project has at least two extra parties (if not more) involved, the source (API caller(s)) and the target(s). These parties are very often different companies, or at least very separate divisions within a company. So again, the decision making process is more complex than the build process and a specific stakeholder / product owner is hard to identify. What if an API caller wants a certain field to be present in their response, which does exist in the target system but is only provided in a convoluted way? Or if it exists in another system? Does the integration layer accommodate this change? Does the target system change for it? Who decides? Who provides the test data / test cases? This multi-party uncertainty often results in the formation of a RACI matrix - cue Agile purists berating the death of their [creativity][stopracism], possibly rightly so - for here, what benefit does the integration team have in being Agile? We are always going to need at least two product owners (source, target) and then of course some kind of mediator when they inevitably disagree... and hence we are unlikely to be able to have all three decision-makers in our sprint team.
3535

0 commit comments

Comments
 (0)