This post is the text of an article I wrote and internally published on Friday, 27th April 2018 while working at NBN Australia to provide an Iteration Manager aka Scrum Master retrospective the day before our next Program Increment planning session. It’s from a point in time where the Iteration Manager (me!) was looking at what’s changed and what challenges are still to come for the development team.

Who the team is

About us

We are the Network Construction, Physical Network Inventory, Software Delivery Team One (NETCON PNI One). Proud to be making valuable software at NBN.
Our team development “name” is Fort Knox. Why? From our good friends at Wikipedia

Fort Knox is a United States Army post in Kentucky south of Louisville and north of Elizabethtown. It is also the site of the United States Bullion Depository.

NBN’s physical network inventory is the gold in Fort Knox and our team are the keepers, maintainers and protectors of that wealth.

and

Our Team Objective

At PNI we will own our own tools and services with quality and knowledge.
Through a focus on

  • increased quality (reducing defects and enabling more efficient coding)
  • increased flow (decreasing the time taken from idea to production use)
  • increased automation (to increase our efficiency and quality)
  • increased use of Confluence and JIRA for sharing information 
  • increased depth of knowledge
    • for our tools and services
    • for how our business uses our tools and services
    • for how we integrate these tools with other teams in the value stream

Please see our Service Catalog for a list of the tools and services which we own.

 

 

One hundred and forty-two days

Today it’s been one hundred and forty-two working days since I started working with you and as we approach the eve of Program Increment Four, in looking back on our journey so far it reminds us of where we’ve come from as a team and what’s still to come on our Agile journey.

The daily stand-up

  • Our focus was on the card or the post-it note on the Kanban board
  • We went through each card tracking the status of items
  • Today we’re taking it in turns to answer the Daily Stand-Up Questions (what did I do yesterday to help the team finish the sprint, what I will do today, and what obstacles are getting in our way)
  • We’re committing to what we’ll do today and making that commitment to our teammates and in front of them
  • We’re physically touching each item, marking with a pen which items have been worked on the previous day giving each of us ownership and readily showing if cards aren’t getting attention
  • Every team member speaks at our stand-up, no one is silent
  • We’re using cards printed from JIRA, no post it notes
  • We have our photo on the card that we’re working on today so that we know who is working on what
  • If it’s work, it’s a card on our Kanban board
  • As a team we decided on a new look Kanban board during SAFe training and as a team we built that new board
  • We display our sprint goal on our Kanban board to ensure that we stay focused on the sprint objective
  • We use a different coloured card for each sprint so that we can track flow across our Kanban board
  • We use our names, not “he” or “she”, during our turn
  • Our cards show the business priority of each item for that sprint in numerical sequence and we work on higher business priority items first
  • Our cards also show the expected release date of that item to keep us focused on timely completion and highlighting Monthly Release items
  • We’ve started to self-organise; given an issue the team will work out how to fix the issue (sometimes with a little prompting eg. who’s going to spend all night awake supporting the monthly release)
  • When teammates use the word “try” we use our Yoda poster to remind us that “try” isn’t in our vocabulary and “do” is
  • We remind ourselves with our Dilbert poster that “almost done” isn’t “done”
  • We also remind ourselves with our Banksy poster that there’s always hope, even if it can be hard to see
  • Sometimes we have to remind ourselves to ensure that a card is (re)printed for a mid-sprint change in scope
  • Our daily stand-up’s are too long, often taking thirty minutes with the recommended duration being fifteen minutes; sometimes we have a lot to talk about and we should do that after the stand-up in individual groups

Kanban Board – Monday 25th September 2017 (mid sprint)

Kanban Board – Thursday 26th April 2018 (sprint commencement)

 

Iteration/Sprint Planning

  • We didn’t do classic Agile sprint planning: previously we had work pushed to us, allocated, today we pull the work in
  • We meet as an entire team with our Product Owner and Business Analyst, we decide as a team what we’ll each work on in that sprint
  • We plan our sprint work breaking it down into who will do individual story sub-tasks
  • We estimate our sub-tasks (design, build, test)
  • We fine-tune our story point estimates
  • We use our Definition of Ready to make sure that work is in a fit state to commence
  • We use the same mechanics for each sprint planning session confirming our capacity, any carry-over from the previous sprint and run through our checklist
  • We use a whiteboard to visualise our sprint planning
  • We agree and commit to our sprint at the end of our planning session

PNI One Sprint Planning

  • We need to do more work on improving our flow, the rate at which work items go from the backlog and into production use
  • We still need to work on our story splitting: once we had 40 Story Point (with one story point equivalent to one person day) items which took several sprints to complete, today we have set a maximum of 8 points and are actively reducing this to 5. We need to keep doing this.

 

Iteration/Sprint Grooming

  • Sprint grooming was done by select team members now it’s the entire team with our Product Owner and Business Analyst
  • Grooming runs mid current sprint for the next sprint to ensure that we’re ready to start that next sprint
  • We actively use our Definition of Ready and if a story isn’t then we work out what needs to be done and do it
  • We estimate our stories as a team often using Planning Poker
  • We identify who will execute UAT and through our Product Owner we make sure that they’re informed about that future work

The PNI One team fine tuning a sprint plan

  • We don’t have in JIRA one unified and sequenced backlog in cases where we need to pull in additional work from either the next sprint or from the JIRA backlog; we need to do deep backlog grooming across more than just the next sprint (this has now commenced with PI4 grooming/pre-planning)

 

Retrospective

  • We run Retrospectives each sprint which are documented on Confluence with follow-up actions
  • We pick one item from each retrospective to work on in the next sprint
  • We know that Retrospectives are a collaborative team event owned by the entire team, not the Iteration Manager
  • Everyone contributes in Retrospectives
  • We don’t always complete the follow-up actions
  • We don’t always add an improvement item to the next sprint

 

Program increment planning

  • We use the Goldilocks principle to plan for PI (just enough: not too much, not too little)
  • We document our plan on Confluence and in the past we used Excel, now we use dynamic JIRA queries in Confluence eg Program Increment 4 Status
  • We estimate our capacity per sprint across the entire PI taking into account leave and public holidays eg PI4 Planning – PI4 Team Capacity
  • Previously the entire team didn’t attend PI, that’s changed/changing with PI4
  • We document our PI and store this on Confluence
  • We run and document PI retrospectives to ensure that we follow Deming’s “inspect/adapt” cycle eg PI2 Plan – Retrospective
  • We report on the status of our epics during the iteration eg. Program Increment 3 Status
  • We need to ensure that we have adequate time to review candidate epics and create stories ahead of the actual PI event
  • We need to set a cut off for new epics ahead of PI
  • We need to identify the epic owner from the business (and make them the epic owner in Jira) so that we know who we need to have conversations with
  • Having just started with PI reporting we need to make sure that we keep doing this eg. Program Increment 4 Status

 

The product owner

  • We had 8-12 offsite based product owners who per our Attendance Register rarely attended Agile events such as the Daily Stand-up, Iteration Grooming, Iteration Planning etc.
  • We now have one engaged Product Owner who sits with our team and attends our Agile ceremonies
  • Sometimes our Product Owner isn’t always available to attend the daily stand-up due to other commitments
  • We rarely have business representation on our floor

 

Information sharing

  • As a team we’ve made a commitment to using JIRA and Confluence rather than email
  • We’ve rebuilt our Network Construction PNI One Confluence site, streamlining the display of information and making it easy to find that information

The importance of having fun!

Celebrating the first time we completed a sprint within a sprint

 

Quality and process

  • We have our Definition of Done and our Definition of Ready on display adjacent to our Kanban board and in our work-space
  • We have printed copies of the Agile Principles and the Manifesto for Agile Software Development at each of our desks
  • Before any code is merged which fixes a known production issue we document the Root Cause Analysis, this helps us to address the underlying issue and stop it from happening again
  • We announce to our business sponsors after an implementation/release to production via email a link to that functional change eg. 2018-02-08 HotFix
  • We make it easy for us and interested parties to know what the status of our work is eg 2018-04 Audit and 2018-05 Audit where we show what’s been released in that month, what we’re planning to release, stories that are in transition or have achieved UAT/SIT sign off or are in the progress of UAT
  • We’ve started documenting our mandatory Non Functional Requirements
  • We have a calendar of events adjacent to our Kanban board which we now refer to for sprint, increment, BAU, MR and SAFe program activities plus who’s on leave – we plan for the future and know what’s planned for us
  • We have our own mission statement with the Network Construction PNI One – Our Team Objective
  • We built an ITIL Service Catalogue in our Master list of all NetCon PNI services and tools to act as the one-stop shop for information about our tools with links to the design documents and work instructions
  • JIRA story titles now commence with the tool name then the functionality to be built, this makes it far easier in JIRA to see what stories are coming up and what tools these affect; easier for us as a team and anyone else using JIRA
  • We’ve created short names for some of our tools. eg. RAPID (Re-allocate ports in DPU) and PABL (Progressive As-built Loader), this personalises our tools and makes it easier to refer to them with one consistent naming scheme
  • We use our Network Construction PNI One Confluence site to track BAU & HotFix releases and to plan and report (commenced with MR 2018-04) on our Monthly Release

 

Scaled Agile Framework Team Self-Assessment

  • UAT testers often now sit with us during UAT to ensure that they have easy access to team-members
  • Originally due to the many offsite Product Owners we took photos of our Kanban Board every few days so that they could benefit from our Kanban board, we still do this to capture change over time and make our information available to those who are offsite
  • We don’t email development team status reports, we send links to reports that we’ve created on Confluence eg. MR 2018-05 Status Reporting and for Iteration Manager Reporting – this ensures that we have transparency, a key tenant of Agile; we make available everything that we’re doing to anyone inside NBN who can access Confluence
  • We reflect on our transition to Agile and document these by undertaking Scaled Agile Self Assessments
  • We use our Confluence site to document our processes from JIRA Story Cards Printing – Internet Explorer to Storm Menu Item Enablement Process and JIRA Process – task flows
  • We apply continuous learning and development and capture this is in our Education & Learning pages eg Story Mapping
  • We document Known issues/limitations with our tools
  • In the spirit of Agile transparency we have Activity Streams showing what each of our team members have been working on in JIRA
  • Recently for the Cut-In Capture Rollback tool we faced a dilemma whereby code which had been written some weeks prior needed to be refactored (rewritten) to take account of new Sonar rule and it was discovered that our original code used libraries which needed to be replaced at the eleventh hour just before a production code merge. The dilemma was to simply push the code into prod after the library changes had been made and not repeat ST and UAT however, we have testing principles which we adhere to and Quality trumps Delivery, so we executed a full round of ST and UAT on the updated code and found a number of issues (caused by the replaced libraries) which would have caused production faults. There is a reason that we test everything before deployment: the compound cost to NBN of an outage/tool issue increases exponentially after release. Finding issues during development costs NBN far less and a quality tool requires less maintenance than one rushed into production.
  • We need to do more work on Story Point Estimation and review our estimates against actuals to increase our accuracy
  • We need to pre build our release announcements ahead of release and send them out the morning of a release
  • We need to add further detail to our Master list of all NetCon PNI services and tools and fine-tune the descriptions of our tools
  • We need business representation at our Sprint demo/Showcase events, it’s rare for questions to be asked about our showcase and with this we miss out on an important inspect/adapt feedback loop from our business colleagues
  • We need to do more work on Non Functional Requirements capturing these against our tools and services in our Service Catalog
  • The 03. Design and 04. Build sections of our Confluence site need more content – we should document how we build (the end to end build process) and how we undertake design (artifacts, processes etc)
  • We need to do more work on educating ourselves on our tools and services, these are often complex and have grown organically with many and varied inherited authors often outside our own team
  • We need to do more work on code refactoring, knowledge capture and building enabler stories to extend our architectural runway
  • We need to spend time enabling Release on Demand, intraday release and improving the ability to deploy our tools and services
  • We need to undertake defect trending analysis to ensure that we continue with the inspect/adapt improvement cycle
  • We need to do more work on automated regression testing to reduce the time taken to fully test our code, in one example automated regression testing takes twenty minutes to execute, manually this would take up to a week (and would be highly error prone)
  • We need a full end to end environment to do our own integration testing
  • We need to do more work on making stories independent of each other to improve flow, allowing individual stories to progress without having to wait for other stories to catch up in the development process

Often you hear that “Agile is a journey”, yes and it’s been an incredible journey with PNI One and will continue to be as we look to the future as a team.
Andrew C. Newbury
Friday, 27th April 2018

And a follow-up article I wrote on 07 May, 2018 to act as short term goals.

SAFe Opportunities

From my OneNote notes on additional opportunities:

Scrum of scrums feedback

  • PO syn engages all POs and IMs
  • Have separate iteration review and system demos
  • How do we build quality into the code
  • Measure iteration cycle time
  • Decouple deployment from release

 

Reporting

  • Anticipated production release dates “on a page” for all epics and stories
  • Confluence page on tests created vs resolved and # automated
  • Epic and Story status summary across the increment, show status and percentage
  • Scope changes for epics and stories
  • Bugs by reporter and assignee
  • PI defects by type, locus & impacted app

Iteration retro

  • One word to describe the iteration
  • Rate the iteration
  • What is missing to make this a better environment?
  • More shared ownership
  • Integrate with other teams on MR activities
  • Implement WIP limits
  • Tasks are under one day, assigned to individuals

 

DevOps

  • Use of APIs & loose coupling
  • Real DevOps… define DevOps at a team level, our team plan and strategy to get there

 

SAFe for teams

  • Implement XP
  • Report on the time used in deployment, testing and support
  • Use of historical data and assume at times like release/launch we’ll be needed more
  • Use www.funrestrospectives.com

 

Team Opportunities

  • Select tools to be rearchitected for increased perf & quality
  • Automatic test generation