Day 1: Session 1 [Arch. Track]: Introduction to Agile Software Development (By: Ahmed Sidky)
Ahmed introduced himself as one that has a master about CMMI and 1st of those to get PhD in software related stuff i Egypt. He spoke in Agile Egypt event before and works in coaching teams implementing Agile. He’s someone who knows what he’s talking about.
“Agile” means flexibility. “What would you do if the customer came to you saying he can only afford a single day of work ? Hint, based on what you provide, he may find a value in investing in one more day of development”. While many in the audience said that they may provide a prototype (which Ahmed interpretted as non-functional one), he wanted to remind us all what our job is. We are not software developers, as software means nothing to the customer, we are “value providers”. A prototype will not benefit the customer. He’ll not gain/save money out of it! What you want to provide in only a single day of work would be the smallest piece of working software, the most important single feature you can develop in a day maybe. Again, until the software is working, it has NO VALUE. You should start giving you customer true value that he only then can afford another day of development!
Agile is all about this, “value driven”. In the 60s when people started to note the major problems of the very limited software at that time, “over budget”, “doesn’t meet schedule” and “don’t meet expectations”. Later, Waterfall came to solve this, but still in the 90s we face the same problems. A paradigm shift was needed. People started looking to the industrial process management to learn from. That’s where all the stuff like CMMI came from.
Later, in 2001, 17 practitioners started thinking: “What are we doing right”. They didn’t come with something totally new, but were looking to things that already existed in the late 90 like eXtreme Programming (XP) and Scrum. They introduced what they called “The Agile Manifesto“. It didn’t aim to be be a silver bullet or a solution to everything, instead, it focuses on “showing us our existing problems early enough”.
A Flexible Process
To dig into Agile, Ahmed first introduced the “Process theory”. There’re two kinds of processes:
- Defined Process: Where you guarantee that whenever you include the same input in the process, you always get the same output. This applies to industry, but it -by definition- does not apply to software. If you give the same requirements to different developers or even to the same developer in different years, would you get the same software ??
- Empirical: That’s just the opposite of the defined process. The output is always subject to change.
Continuing, and in many other parts, I felt we developers were sort of wrong audience for this session, as a lot of talk I believed was for project managers more than for developers, although we had a debate about that point. Ahmed went talking about how most PMs try to treat software as a defined process “Get all specs then build”. Don’t they try to put fixed estimate for the software? How would you get that unless it’s well defined? (A quick note was that there still are ways to get fair close estimate with empirical process as well). He talked about the story of trying to create a house in 4 hours. It was planned for 4 hours but was actually even done in 3.5 hours, but hey, it took 6 months of planning!
This is what we (I think he means PMs) try to do with software. But it doesn’t work. A great situations Ahmed told is that he once said to a customer “Do you want to 6 months to get you something you don’t want or wait 2 weeks to give you something you don’t want ??”. Because we all know the very first release of the software will not be what the customer really need. Adaptation to change is by default. The key is: “Inspect and Adapt (change to fit)”. Ahmed confirmed, this is just a different mind set. You could be doing Agile while still using existing process like CMMI.
Ahmed went first on more detailed talk about the Agile Manifesto. The manifesto says:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
A point highlighted was that the right part after the word “over” in every line is still valued, it’s just values less vs. the left side. He asked, when the deadline is getting close, and you are missing features and specs for them, would you focus on documentation or working software?? The point is, we all already follow this manifesto, but we normally only follow it “IN CRISIS MODE”.
Then, Ahmed moved into the key principles behind Agile (sample details). First, the highest priority should be customer satisfaction. After all, that’s the one who pays for the software :D. You achieve that by keeping a value stream, that means keeping an early continuous delivery of valued software.
Another principle is welcoming requirement (plans / expected results) change – eve if late in development! Of course it should be understood and even communicated to the customer that this does not come for free. If the customer accepts the cost of change (time/money), then they should be welcomed. To know about the change as early as possible, we get to the next principle, deliver “working software” frequently (2 weeks to month), with preference to the shorter timescale. Also, another related principle is that business people should work daily throughout the project. Of course business people does not mean the customer here, but the business analyst
The next one is interesting; Build around motivated individuals, the motivation is expected to a result of the team’s self management nature. Also, another principle almost already mentioned is that working software is the primary measure of progress. The key point here is that your progress is not where you are in the plan (requirements, documents, design,…), if your plan says you have 2 months to finish and the actual takes 4, this means you were at 60% of progress, not 80%. Other principles are abut promoting sustainable development, and simplicity.
Then Ahmed went on confirming, this is all best for self-organized teams. The whole team reflects what’s gone wrong / right and realizes the need to change. The paradigm shift to “Value Driven” approach makes you consider delivering the highest value at the beginning. Sometimes up to 45% of the features in some projects are almost never used. In agile, the client tells what he wants to be developed for the next iteration. He knows better what makes best value to him. Of course there still should be a planning iteration.
Afterwards we saw a picture of 15 or more developers sitting on their desks in a cube-less office with dual monitors per desk (the dual monitors reminded me of the office in SilverKey!) and having a big data show monitor. On the walls so many sticky notes with different colors, one is red. That was room for Ahmed to explain the value of pair programming, code review, and the very interesting walls thing. The sticky notes on the walls were actually work items, yeah, features and bugs. A manager passing by can easily see the walls as a real-time graph of functionality vs. quality (feature progress vs. amount of bugs). This is the point here, visibility and communication vs. cubes! It’s that developers are people, not resources, which even inspires the point that people have good days and bad days as well.
Of course agile promises that this can achieve customer satisfaction as well as team moral. It comes when all the developers have enough common understanding (remember, the developers altogether put the estimates) of the risks, system design, and have a common perspective about the whole project.
The last thing was promoting again practices like automated unit test (yeah, and TDD), and pair programming. and reminding that agile is all about minimum process, yet, maximum value.
I think the session was one of the good sessions in EDC, mainly a very quick skimming and introducing practices. Some areas I felt targeted PMs (who are not intended audience of this conference), but maybe I say that as I’m over concerned with “delivering process to developers” since my dotNETwork session (also on agile), “Scrum For Developers“. I think in general Ahmed is a very heavy speaker. I’ll love to attend a session he presents, hopefully on more advanced level topic (God Willing).
How did I learn that?
As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.
It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2+, ASP.NET (4.x/MVC5 and Core), and other fullstack developer goodies.
Take it for a test ride, and you may unsubscribe any time.
You might also want to support me by checking these out [Thanks]: