Wednesday 14 August 2013

Agile Africa 2013 Conference - Day Two


Yesterday was Day Two, concluding the very first Agile Conference in Africa, an event that was organised in a short space of time (2 months) by a team of just five people - hats off to the event organisers and sponsors. Indeed it was quite a significant milestone, a stake firmly grounded that Agile in Africa is growing. 

The second day was filled to the brim by an impressive lineup of speakers, a bit over ambitious in my humble opinion, since sometimes the audience needs more time with the keynote speakers (1 hour isn't enough), and on starting late and not keeping to time, something that could be improved for the next conference. Having said that, the day was awesome, personally, I took away a different kind of appreciation for the companies in Africa, bold enough to push Agile adoption, the openness and willingness to experiment and being OK with failure...

The talks that really resonated well with me included Martin Fowler's keynote, Ana Forrsman's review of JSE's agile experiences, Derrydean Dadzie's first time mistakes clash of Corporate/Start-up culture & Aslam Khan's sharing of personal challenges of teams operating Beyond Apartheid & Democracy (so relevant today, but people walk on eggshells around this. I myself have observed, even today, the subtle office racial nuances at play even in 2013...). I also appreciated Ivar Jacobson's first-time presentation introducing the SEMAT kernel, although I really had background knowledge of this concept from earlier this year - I think most people left that talk wondering more about the wider implications of SEMAT kernel and effects of "formalising" a way of working or thinking when it comes to producing software...

I have briefly summarized my take-away and notes here:
Software Design in the 21st Century - Martin Fowler
I was looking forward to this keynote, only gripe is that one hour just isn't enough time to allow for such keynotes. Martin split his talk focusing on two topics: Agile Fluency & Value of Software Design. Martin shared the original concepts of Agile fluency from the paper by Diana Larsen & James Shore. In a nutshell, the Fluency model is based on a star-rating system, starting with one-star that focuses on the fundamental elements of mindset and culture shift through to three & four-star ratings where the entire organisation is transformed. Achieving organisational transformation is really difficult to achieve, very few teams can do this, not many companies sharing this kind of data. The Agile Fluency model is something worthwhile assessing when teams are starting on their journey with agile. Incidentally, the team members from our group, reflected on this model, and despite what we may have thought originally, the team aren't even close to a one-star rating yet!! So enlightening indeed.
On to the value of Software Design - the core message from Martin focused on managing technical debt. Drawing on the analogy from financial markets, i.e. paying off a loan or principal debt with interest, technical debt can be managed in pretty much the same way. One can be reckless either deliberately or inadvertently, or one can remain prudent making conscious decision to go with shipping now and dealing with the consequences later. There is also the scenario where the technical debt is revealing lessons learnt "Now we know how we should have done it". 
Another key message was that technical team should not use the moral argument for projects granting leeway to manage technical debt (i.e. clean code, modular architecture principles, etc) - in the face of an economic argument, economic rationale will always win. But when technical debt is argued in terms of cost and return on investment, short-term loss for long term rewards, etc - then management will be more receptive.
Finally, Martin touched briefly on Evolutionary Design - I wished we could have spent a bit more time talking about Architecture Design since this is a topic of contention in most teams - do you design just enough based on the information at hand, or do you maintain some foresight. IMHO, where the technology or product domain is pretty much new and disruptive, I am all for doing just enough and adapting till we settle on a reasonable architecture, but where the technology/product has a lot of prior art out there already, where competition is indeed aplenty, such as Set-Top-Box software stack, then it makes sense instead, to attempt an architectural mode with foresight than spinning wheels each time a new feature increment is added...

Check out:
Rough notes on Tech Debt topic
Agile and SEMAT - Perfect Partners - Ivar Jacobson
I was fortunate to have had some prior knowledge of the SEMAT (Software Engineering Methods and Theory) kernel, came across it a recent ACM journal article (I subscribe to ACM & IEEE software journals to keep abreast of topics even though I may not be coding anymore).
This was Jacobson's first presentation of SEMAT, I think more time should have been given to this keynote, especially since the relatively new state of this concept, and more especially since people fresh into Agile don't fully appreciate and grasp that even though we say be nimble and agile, there's really no excuse for poor software engineering principles, taking shortcuts, averse to some kind of structured processes.
Jacobson maintains that SEMAT/Kernel is not a new hype. The founding group had spent four years developing the kernel. He maintains that even though decades have past in the annals of software engineering, the truth of the matter is that Software Development field is still pretty much immature, fairly young -- there are just too many ways of doing software. Even this disparity is experienced within departments of the same company, possibly different teams of the same project have different ways of doing things. Whilst there is no one-size-fits-all for software, the belief is that all software projects need a foundation for software development.  
The SEMAT/Kernel attempts to add some structure to the software development process, whilst maintaining fluidity so much so that it is really not at odds with any Agile/Lean principles. The Kernel, called Essence, is a simple state-driven model for software development, providing a shared frame of reference and common vocabulary. People have started applying these concepts, but it will take a few years to go mainstream. 
Attempts are being made at introducing this into the software engineering curriculum. 

Check out:
To be Agile or Not to be Agile - JSE Corporate Perspective - Ana Forssman
Ana claims not to be from IT, she is Director of Market Data from JSE (Johannesburg Stock Exchange) Market Data Division, providing investment related products to clients. Like any stock exchange, this is highly critical operations, real-time, lots of money involved. 
I was totally blown away and humbled, enlightened and motivated by Ana's talk - she really knew her stuff, talked both the business and IT language with ease and commanded a firm grounding on the experiences of Agile.
They decided to experiment with Agile, aim to automate their entire division: all market data from all sources automated, this data enables investors to determine whether SA is a viable trading option. Automation was also needed because the division was growing rapidly, automating their processes would enable efficiencies & support the anticipated growth.  
Guided by Thoughtworks Consulting, they started their agile journey just over a year ago. The team are now pretty much self-reliant, fully in control of their own destiny, with IT & Business collaborating ever so closely together. They've delivered two releases so far, every deliverable has been precise, on time and exactly what the product owner wanted!
Ana talked around a few key slides, see below. For each point, she expounded on the real lessons learnt and provided advice for others. 
Key messages:
  • When you start on this Agile journey, be prepared to suffer pain in the first year. If you don't suffer any pain, then you're probably not learning or doing something wrong
  • Engagement and commitment from the business sponsors and client engagement in eliciting value based requirements is critical to success
  • Pain level is as high as people resist the process
  • Good to have people who are catalysts willing to try new thins / changes - they're open minded and will be natural champions to change as catalysts for change
  • They've taken on the Mingle system and have adapted it to suit their needs - no complaints (I'm checking this tool out soon)
Dadzie's talk was about the experiences and life/project lessons learnt of a fairly young start-up entity (DreamOval Ltd) from Ghana experienced in one of their first major, large project wins with a big corporate bank. The talk was fresh, presentation style unique and story typical: Large Enterprise (long history of heavy-winded processes) CIO-sponsored project meets young, energetic, dynamic team that gets stuff done, with little process. The story was around this new CIO, just two months into the job (different culture, not from Ghana), kicks off an elaborate project, on such a large scale without buy-in from internal stakeholders. Grand architecture ambitions, disregarding the foot soldiers, CIO sponsors multi-project teams, each project working in isolation from the others, no unifying vision or scope, teams working in isolation, little pockets of components working, but system dysfunctional on the whole - break down in communications, delays, anger flares, turns messy - how does the young team flourish, maintain a pay cheque and prove that value is being produced for their part??  
Messages:
  • The more deeper they went into the project, the more gaps they discovered. CIO didn't get buy-in from internal managers. CIO believed most people in-house "just didn't get it". Many teams ended up working on different projects with different methodologies
  • Focus more on processes over tooling - don't impose tooling as a means of communication. Stakeholders won't go online to view your backlog or burn-up. Find a way that works, e.g. CIO was keen on Excel
  • Contractually set price & date in a fixed-cost project otherwise hang on strong to scope
  • Success of a project doesn't just depend on one person alone (team collaboration). This CIO alienated his own internal team
  • Training is always helpful. Advocate Agile continuously - don't assume people will get it the first time round. Take time to talk to the customer about your preferred way of working.
  • Depend on the product owner to remove obstacles.
  • Enterprises have to learn their true DNA or be willing to re-engineer their mindset
Enterprise Agile Adoption with Parental Guidance - Riaan du Toit
This talk also could have done with having more time allocated, but instead was somewhat rushed and constrained to 30 minutes, which probably isn't enough time to allow for the key points of DAD (Disciplined Agile Delivery). Riaan went through a slide pack building up the story behind DAD, eventually rushing through the core areas of the DAD framework. I will have to dig into DAD a bit more, incidentally a lot of the stuff it talks about, some large projects may have already been doing it, a.k.a "common sense", but at least DAD offers a hybrid model that satisfies and integrates traditional enterprise management structures, with that of iterative, agile and lean project management & delivery. 
What was an interesting take though, was the manifesto-like speak in the DAD message: DAD extends Agile thinking:
  • DAD talks about appreciating Stakeholders, not just customers
  • Solutions delivery not just software development
  • Organisational ecosystem focus not just focusing on development teams
What is also interesting is that the framework talks about initial phases of Architecture, Planning, Iterative cycles. Traditional organisational roles / responsibilities are also mapped into spaces suitable for the Agile shift. The framework also seems to support Team/Project/Program/Portfolio enterprise organisational structures. 
See slides below that captures the essence.

Beyond Apartheid & Democracy - Aslam Khan
This topic, although most people might get uncomfortable and edgy around this, is quite relevant and pertinent to the South African context of team building, team cohesion & forces us to be quite reflective, objective and critical about the reality of team gelling -- given the cultural and political history of South Africa.
As ideal as the Agile principles might be, there is the reality that creating a self-organising, highly collaborative team is difficult to achieve if one ignores the human social & psychological dynamics of the team itself.
Aslam talked us through his own childhood, upbringing during Apartheid (incidentally he was from Pietermaritzburg, same town as me, we share same surname but no relation) and his own experiences of protesting, standing up for independence, clashing with police, etc -- which resulted in a lot of hatred....So Aslam drew parallels with SA's political history, quoted Bob Marley a lot, and told the story of a past project (though quite recent in the young SA democracy 2006-2008) where the project really turned quite toxic, due to human / people issues, to the point that his team had to find the opportunity to exit the project eventually.
Having exited the project, Aslam felt really uncomfortable with not getting closure, spent the next couple of years to find an answer, and thus came about this political metaphor.
It then dawned on him, the stuff that really made SA's transition peaceful into the new SA, was the fundamental concept of the Truth & Reconciliation Commission. This is a forum where people are allowed to share their feelings, emotions, lay it all out, open wounds, discuss, share, make it known, reach closure and work on ways to changing the outcome going forward.
This process is exactly what real retrospectives should be like - don't allow teams to continue with an undercurrent of mistrust, dysfunctional moments, etc. How does one move away from contempt (individual goals with no integrity) to Co-Operation (shared goals, working on Integrity) through to Collaboration (preserving integrity and working on Identity)?
Nurturing identity cannot be time-boxed. Identity is not about giving your team a name and printing out avatars - this is tribalism! Aslam would like to create an identity for African software teams: Restoration & Creation of an African identity.

Bob Marley quotes:
Many more will have to suffer
Many more will have to die
Don't ask me why

Kwane Nkrumah
We face neither East nor West; we face forward 
My take-aways: I could absolutely relate to Aslam's story, and even today, after spending two years in SA since being away for ten years in Europe, in 2013 it is still quite apparent that teams still have this "us/they" thing going one, level of mistrust, respect isn't always there, and the undercurrents of the racial divide is still around, it is subtle - but it still remains. I found this quite difficult to accept, but it is a reality unfortunately.


Beyond hype and dogma: How South African teams increased their value - Martin Cronje
Martin shared some of his results (case studies) from spending time coaching various teams on the road to successfully adapting to Agile. From his experience, Martin reckons working software is the only real measure of progress. He also echoed the sentiments just as Arrie presented on day one, it is about common sense, really.
My key take-away is that it is completely possible to make effective use of Pomodoro technique.
The rest of the messages summarized in point form:
  • Communication is always the number one issue
  • Resistance from stakeholders
  • Do one small thing at a time
  • Teams feared that transparency will expose them
  • Too many inexperienced engineers - avoid
  • Fear and hope of random buses
  • Making legacy code agile
  • Dramatic drop of defects
  • Focused on essential needs only
  • Cycle times improved
  • Deep issues can be addressed in retrospectives
  • Improved team cohesion & morale
  • Use metrics to leverage organisational change
Measuring Throughput - Danie Roux
I probably can blame this review because it was getting late in the afternoon, head heavy with the previous speakers take-aways and my natural aversion to anything remotely related to financial accounting (I'm a South African Indian yes, but never been interested in accounting!). Sadly I can vaguely remember much of this presentation about effectively measuring throughput of the team, how that affects the return on investment and using these metrics to influence the decisions made higher up in the organisation - message being that we must adapt our way of thinking / value generation by taking into account Global & Local optimizations.  I tried hard to think about how I could use this in the current organisation, but like all other very large, somewhat monolithic corporations, getting your development managers to make an upwards dent into global optimisation will be an almost herculian task, unless that company is suffering financially...
Anyway, worth checking out:
  • Books:
    • The Goal - Goldratt
    • The principles of product development flow
    • The haystack syndrome
    • Throughput accounting
Software Development Revolution in Africa - Ernest Mnkandla
Nothing much revelational in this talk unfortunately, started late and had further technical issues with the projector - was difficult to follow the talk. But I did leave with an appreciation for Earnest sharing his metaphor for software development timeline as a kin to the human development cycles: mapping the software timeline milestones as moving through: childbirth, infant, toddler, child, teenager, adult years, etc, etc. And finally the core message that just as Africa capitalized on the telecommunications challenges the rest of the first world faced in terms of fixed-line, whilst Africa made the leap to wireless and now considered an innovator in that field. In the same way, with Agile, we should learn from the experiences from the western world (stand on the shoulders of giants) and not make the same mistakes...at the same time, it ties in nicely with finding a model that fits well with the culture of the African people.

Questions and Answer Forum
The closing keynote speaker was a no-show (passport problems), so we had an impromptu Q&A sessions with Aslam, Barry (JCSE) & James (Thoughtworks).
Q: Do conferences many any sense in this day and age, connected world, could it be done via online, etc?
A: Barry - It makes a lot of sense to meet face-to-face, we need the social context. Energy seen here from this conference convinces me more we do have to meet in person from time to time.
James - Yes, physical interaction is important - technology can't replace human elements.
Aslam - Conferences invites us to have conversations in the corridors, networking is invaluable
Audience - In Africa, meeting & talking is part of the culture, that's why we go to weddings.

Q: How come we don't have more local speakers?
A: Barry - Since this was a first time conference, we needed international speakers to attract / draw the crowd. As we build the brand, we will get more local speakers.
Aslam - It has been a challenge to have local keynotes, but it's nice to have international speakers - the gathering was a reasonable one.

Q: How can we improve getting more black/African speakers?
A: We definitely need to bridge this gap, but this was the first time conference, put together hastily. We do need more people submitting presentation / papers for review. There is local talent out there, we need to explore ways of making this accessible...

Q: Opinion of State of Agile in Africa?
A: In SA, agile is still very young. The rest of Africa, the penetration is low. Conferences are good for people already in-the-know. Workshops are probably better suited for newbies. Other ways need to be explored, such as education....people should feedback their insights...

Q: Lots of buzz around gamification, having fun, etc. Should we in SA be focused on discipline & fundamental principles?
A: Barry - We need to see ourselves in terms of human development. See ourselves as the mobile revolution where we skipped fixed lines where SA is now leading mobile revolution. Think Africa could be driving Agile-innovation in the same way.
Aslam - Experiment and see what works. Don't put money on one horse on gamification, doesn't work like that.

Q: Do you think universities are aligned with the software industry?
A: No. they have lots of catching up to do. Very slow in adapting. Academia need to do a lot more, universities are not in alignment.
In Uganda however, universities have started integrating open source, beginning to see change there.
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)