Agile Business Solutions

Tag: agile

  • WFH Working from home

    WFH Working from home

    Covid-19 the great disruptor. Disruption.

    I’ve been used to working from home one or two days a week for several years. So when the coronavirus situation turned here in the UK and the need to WFH was announced I thought I and the team would be prepared.

    In reality, it was far from it. The first stand-up call failed. Too many people were working from home and the conference call infrastructure buckled. I spun up a free Zoom account. It took several hours for the confirmation email to percolate through the layers to my client O365 account, but next day the team could at least hear each other clearly.

    Several other team members registered accounts so it became difficult to know which one to use. If one failed we switched to another, but at least we could do team sit down stand-ups.

    Our usual team conference call package also bundled chat, along with IP telephony so we switched to MS Teams for chat. Only problem was the Teams client had not been rolled out so we had to use the web browser client. This consumed nearly 0.5Gb of memory and was dog slow on my ThinkPad. So I switched back to old chat and had two channels now to monitor.

    Teams would send an email when someone was trying to reach me. Another distraction. I could probably find the notification preference buried somewhere if I had time. Why not just email me I thought? I now had to monitor email to check Teams that took ages to load only to find someone has sent a morning greeting!

    We take communication for granted. We take time to learn how to use the new tools and use multiple tools effectively. It will improve.

    Team members, especially new to WFH shared tips. Simple things like taking a break, making sure your screen is the right height, having a comfortable chair, speaking to others rather than typing out messages all helped remind me of things I take for granted others may not.

    Childcare is obviously a real issue for some with work and family life intermingled. Soon toddlers appeared in the team meetings with the sudden dash to catch a wayward one from mischievous adventure. It all seemed funny but very serious as well. A tension rarely seen in WFH before.

    Exercise needs discipline without the mandated daily walk to the station and office commute. It’s all too easy to forget to exercise and healthy concentration soon suffered.

    Social groups and interaction – so much has been covered and virtual coffee mornings soon appeared in the calendar to replace the office kitchen banter that we take for granted.

    Social games – relieve stress. Online quizzes, endless funny videos consuming precious VPN bandwidth and even Eurovision style contests helped ease the strain of lockdown.

    After 8 weeks of lockdown, lunacy or more correctly well-being mindfulness raised in importance. It is hard to keep pretending this is normal. It’s not the new normal. But we will battle through.

    It’s interesting to think what could happen to cities if the great exodus to WFH remains the new normal after measures are slowly removed. All the office space that can only allow 50% or 25% occupancy. WeWork clusters that have an even tighter business case. The realisation that for some types of office work the need to be colocated was a myth and teams can be productive using remote working tools.

    Could there be an inversion with the move away from living in cities to the tranquility and greener countryside? Will house prices flip and London rates decrease as the supply exceeds the demand and offices become living accommodation? It’s interesting to ponder on the new economics of a post Covid-19 world. If there’s ever such a place.

    Not everyone can and will want to WFH so the shift is likely to be moderated. But could the high-street in towns and villages return to offer an escape from home office life? Local WeWork style venues like the coffee shops with wifi but allowing social distanced working space as an alternative to the home office. For local meet ups and a change of scene. Many more local social centres of enterprise rather than mass transit to mega city office spaces where hot desking had already removed the ownership of my personal space.

    The continued isolation of WFH will mean change, it’s a disruptor that we can’t ignore.

  • Agile analysts – do they exist?

    I like to think I’m agile. Most of the time I’m working as an analyst on projects, split between business and system analysis tasks. I talk with the business experts and help them define their requirements from requests to change or add new behaviour to adapt to business needs. In an ideal agile world I’d be redundant, as the business would have resource to allocate experts to work alongside developers in the project team. Fortunately for me and many other analysts the business are rarely flushed with enough experienced business experts and must rely on a go between to convey their message. I like to think I add value by removing any preconceived notions the business may have in specifying how they want the new functionality to work, by filtering their requirements and extracting what they want it to do. I might write a story that details a change to an operational report or define a new addition to the product set. I seek estimates from the developers and feed this back to the business for approval. As a go-between, I’m fulfilling a legitimate agile role.

    But is there really a need for an agile analyst? Is the term an oxymoron? It’s a question often asked by companies starting out on the agile path. CEOs read agile books about empowerment and business sponsors and plough in with pilot projects that bring swift results. They attend seminars and see the productivity of pair programming. Six months or so after the heady kick-off meeting and countless show and tell sessions the business realise they have more work to do than automation can bring. Who’s going to handle the customer support lines? Who will send the white mail and respond to written enquiries? Just what does Sox mean to audit? Soon the full time business sponsor is part time or has little or no time to spare at all. We’ve seen it happen on several projects.

    Beyond the consultant’s vocabulary of business process change and IT infrastructure lays the reality of an end-to-end process. In the haste to embrace agility the business may forget this. But I like to think the analyst never will. The agile analyst can fill the gap when the initial sponsor retreats or play the role of surrogate business expert when full time secondment was never an option. They may even re-badge themselves as product specialists.

    I like to think the agile analyst brings a few more tools and techniques that the businesses sponsor or developer could rarely provide. As an analyst I can create models and unambiguous diagrams that slay endless business arguments. For example, a state diagram that clarify exactly in which circumstances we will accept a certain business event. Or I can create a data model that captures the legitimate rules for relating product to service. It’s true, once these business requirements are understood by the developers my effort if no longer required, I’ve fulfilled my role. But when significant changes are required later on the analyst can again help filter and convey requirements without bias of technical forethought.

  • Agile in practice

    Over the years I’ve practiced various flavours of IT development in projects with emphasis on use case driven approaches to guide requirements capture. Not all companies work this way and for many creation of a lengthy functional requirements document is the norm. Without an FRD / PRD / ReqDoc or whatever the in-house term used, the functional requirements are often fragmented and hierarchical with lashings of must haves, should haves and could haves. And in many of my projects the use case has successfully challenged this status quo with an improved way to cluster and manage requirement complexity.

    Some projects along the use case migration road have not been so successful and there seems to be a trend to these types. A bad smell may begin with endless reviews in which more detail is added and more critique ensues. Business won’t sign-off and development is stalled and eventually the project misses its window of opportunity and is canned. Or the number of use cases seems to keep increasing with ever more elaborate techniques to package, include and extend them. The Business becomes frightened to read or review and loose faith in use case salvation. Or the estimates raise eyebrows and a new project manager is called in to tame the beast. The PM brings along new metrics in Excel; an impressive plan in Project and development begins, milestones come and go. The first use case never reaches QA for test. The project takes a vacation.

    So what’s going wrong and can an agile approach help? Clues left behind by failed or failing IT development projects are useful forensic evidence. Larger companies may have resource to carry out their own post mortem as post implementation reviews. I’ve witnessed two recurring themes from these reviews. First killer is complexity and can be reduced and controlled by user stories. Second killer is lack of iteration borne out of waterfall mindset and this requires enlightened confident management.

    Complexity just happens. It’s often not intentional, use case specification just get longer and more detailed. What starts as a simple happy day with a few sentences becomes a heavyweight monster, detailing a multitude of alternatives and exception scenarios. All parties agree these are important. But the project plan has a single task for the whole use case – there so many use cases so we can’t have separate activities for each one can we? The developers wrestle with the monster use case and may get some scenarios working but there’s never enough complete to make it past QA. One way to avoid the monster is to focus only on the happy day and perhaps one or two alternatives. The use case is manageable and can progress through analysis, design dev and test. Success? Not necessarily as those missing alternatives and exceptions are identified during release testing and requires further iterations to fix the defects. But this is ok, the dev team have been through the build cycle and the team can cope so long as release dates are flexible. Success depends on not getting bogged down during requirements definition and producing something that demonstrates delivery is possible. Agility wins the day by accommodating change – the requirements we skipped over at the start get fixed after some code is working.

    So was the use case to blame? Maybe. Use cases have become collections of scenarios all working towards a common goal – something of benefit to the business. But just as use cases are collections of related functional requirements, scenarios add another dimension and complexity is multiplied. Think about it; with five requirements related to registering new user, if 4 scenarios are identified that’s twenty requirements that need developing and testing. The use case is overloaded and may hide underlying complexity. An eight person-day estimate to code the use case for one scenario may translate to 32 days when all scenarios are included. If early happy day estimates are used to construct the project plan budgets are soon blown.

    A user story helps avoid overloaded by keeping the scenarios separate. The story captures one or two tightly bound scenarios with a crucial constraint – it must be possible to code the story in a short time, say a maximum of 1 week. The agile approach does not allow story bloat. Yes more stories are needed to capture all the scenarios but there’s no insistence that they must all be identified before a line of code is written. Complexity is still there but never all at once. Each iteration builds towards complete functionality covering more scenarios but never all at once. The story becomes the unit of planning instead of a use case that may contain dozens of stories.

    Agile methods talk about story velocity and it’s an important concept. The velocity is the number of stories coded per unit of time, typically in person days. For example, our current team has a velocity of 5 stories per day. Perhaps story inertia is an even more useful term. Consider the effort in getting a development team moving. The larger the story, the more inertia and effort needed in getting it moving but once moving it’s easy to add more stories and get working code out the other end. An agile process starts by keeping initial requirements concise and simple in a few stories so development can get moving – low inertia. Then stories for the alternatives and exceptions are added, refactoring where necessary. Another benefit: later stories don’t need as much detail as the initial story has already defined the main pathway and show the way.

    Contrast this with a full use case driven development in which as many scenarios are analysed and detailed before any coding begins. Picking any use case to start development brings along all its scenarios in one chunk of code. High inertia, a big flywheel to get moving.

     

  • To document or not

    To document or not

    Document Graphic Lipsum and BookFew people really like documentation. Given the option most would rather try to figure out what to do without reading the manual. Even quick reference guide is hurriedly tossed aside to tryout the latest gadget. It’s probably masculine pride and could account for the agile manifesto’s preference for face-to-face communication over written documentation. I’m not saying the agile manifesto favours masculine traits but it’s true the initiators were all male (http://agilemanifesto.org/).

    When a new member joins an agile project face-to-face communication is essential to gain understanding of the system its foibles and its characteristics. There’s likely to be little or no documentation to read. Agile modellers may have left behind some light weight foot prints in the form of iPhone whiteboard snaps or maybe a few diagrams, most likely rendered in HTML and accessible only via a browser. But these are rarely up to date, refactoring and continuous delivery will have seen to that. So to return to the question often debated by projects embarking on an agile course, “Should we produce any documentation or not?” Well, it depends…

    Given a stable agile project team there’s little benefit in documenting much before coding. Simple user stores capture outline requirements sufficient to continue conversations between developers and business specialists. The story’s success criteria keep QA busy with enough to write test cases and outline scripts. After several iterations and releases all the team are in sync so there’s little perceived benefit in retro documentation and the overhead associated in keeping it in sync. Inevitably team members wax and wane and new requirements challenge the agile approach. The Business, flushed with success of early versions may see new opportunities for additional features way beyond the original requirements. These aspects stress an agile project. Without documentation new members must spend time with experienced team players but those left are over utilised in responding to change requests and bug fixes and can spare little time for the newbies. Without a high-level architectural schematic it’s difficult to discuss the brittle points for the new requirements and the developers talk code rather than packages. (Code has its place but not usually at meetings between the business, architects and project managers discussing the latest marketing ideas for product offerings.)

    Documentation helps support the frailty of human memory and schematic models can focus and simplify discussions so that all are on the same page. In the truest agile way these can be generated from a model or created on a whiteboard and don’t have to be lengthy tombs. I’ve found a few core diagrams can be extremely helpful. For example, in a message based order processing application, a state diagram showing the states of an order with its associated events can form the basis for planning development, partitioning stories and organising test cases. While a high-level block schematic can define architectural boundaries and help allocate development teams and identify message interface owners. There’s often little need for pages of descriptive prose or endless sequence diagrams. But one or two physical data models depicting the cardinality between major entities can again focus discussions and ultimately speed development.