agile

Early adopters, Agile philanthropy key points in ADP keynote

“With great power comes great responsibility.” Those were Ben Parker’s dying words, spoken to a young Peter Parker, alias Spiderman. It was also the subtitle of Electroglide Bob Payne’s keynote on the opening day of Software Quality Engineering’s Agile Development Practices Conference in Orlando, Fla.

The keynote’s focus was Agile philanthropy, a term Payne uses to describe the benefits of Agile. Payne discussed the new Agile Philanthropy project, whose volunteers from the open source and commercial software industry assist non-profits with application coding, development and delivery. “This industry has been very kind to me,” says Payne, “I felt obligated to give back.” If you would like to speak with Bob Payne about volunteering, contact him at bob@codegreenlabs.com.

Payne’s other project is transitioning Electroglide, a Washington, D.C.-based consulting firm, and rebranding the company too CodeGreenLabs, a new brand name but one still focused on Agile software development and transitioning companies to Agile. Payne has been an Agile user since 1999, before the publication of The Agile Manifesto.

Typically Electroglide’s ideal clients have been large financial service providers and video game development companies. He’s seen that financial companies are early adopters of Agile. Indeed, he thinks the financial service provider market is in the greatest need for Agile business practices. They usually are already working together on coding projects and only need slightly more-focused guidance to fully work with the upmost agility, he said.

While financial firms are definitely interested in Agile, they can be reluctant to engage in Agile practices. Transitioning normally takes one-to-five months to complete, Payne said, but transition included two Agile projects: one related to technology and practices; another in which the company works cooperatively with Payne to learn the Agile mindset.

In Payne’s experience, the gaming industry has been the most open to Agile practices, largely because the way in which game developers have been creating games already closely mimics the Agile methodology.

While Payne is an Agile evangelist, he did not sugarcoat the Agile way, noting that the Agile approach just isn’t going to yield companies the desired results in every situation.

STPCon: How SocialText uses Agile, wikis and remote developers

At the Software Test and Performance Conference (STPCon) this week, I had the pleasure of spending time with Matt Heusser, a software tester for a social networking software development company, SocialText, he is also a SearchSoftwareQuality.com contributor and spoke in a few STPCon sessions this year.

Heusser focused on his development work at SocialText in one session. He told me he had been preparing for months on his presentation on developing software that helps remote workers stay in touch with co-workers and up to date on their businesses, work agendas and projects. Also, he had the challenge of describing how SocialText uses the agile development model.

In the session, he described SocialText’s model step by step, showing such things as how the client’s work request is handed down linearly to the appropriate team chapters. He explained what happened in client-SocialText developer kick-off meetings, noting that all team members attend online using their networking and communication tools. The kickoff is an opportunity for client questions can be asked and requirements clarified, he said. After that initial meeting, the business model becomes a staircase of iteration constructing events. But the whole team has the availability to follow the project, even at phases they are not directly involved with.

SocialText’s programming and products are based on a wiki, making them easy to modify and fairly easy to write the first place. “Anyone dedicated enough, could write something similar,” said Heusser, but SocialText got a head start in this area.

In SocialText’s agile model, Iterations are normally completed bi-weekly. Once approved, the next functional addition is begun on the approved code. This process recycles through all of the testing. Testing is done throughout the entire development process, so that when “crunch time” come, the team doesn’t have to run the full train of tests. Most are already completed, and the few that remain can be held off until a more appropriate time can selected.

Heusser admitted that their process probably wouldn’t work every software development company. “One of the rarest things about working SocialText, is that we use our software to create new software,” he said. “This helps us in the usability testing. If a function doesn’t work properly, we notice it very quickly, as we use every feature numerous times in the development of every product.”

Another rare thing about SocialText is its hiring of many remote developers. Generally, quality of applicant aced location everytime. “In the 21st century, it is ridiculous to rely on 18th century hiring models. Those who worked in mines and on railways had to be geographically placed in the vicinity of their work, of course. That just isn’t and shouldn’t have to be the case these days. We have the technology, why not use it?”

Ways Agile beats waterfall development, boosts software quality

“How many of you are agile-ists?” Agile expert and author Damon Poole asked attendees this at the SPIN local user group meeting near Boston this week. Then he said: “Agile-ists look like normal people… but if you don’t believe in agile, let me assure you, there is nothing wrong with you.”

Poole gave various examples and analogies of how agile development methodology works, noting that group involvement was a key of agile success. Agile developers benefit from receiving more frequent feedback from customers and having short-term, reachable deadlines, Poole said.

“Agile versus waterfall or any other methodology can be compared to touchdowns versus yardage,” he said. “Where is the credit given? Clearly you can’t win the game based on ridiculous yardage without scoring.”

This analogy points to the major downfall of waterfall, a process in which the team scrambles in all different directions and gains some ground, but often fails to complete the project on time. Agile, he said, is different; you set reachable goals for short phases, or iterations, of development.

This process of “continuous integration” involves completing one set of functional code, getting feedback and then adding new coding to it and retesting. Doing projects in phases assures a higher quality because of multiple tests and retests carried out during the SDLC (Software Development Life Cycle).

“With agile, there is an absence of confusion,” Poole said. “Do you guys remember the childhood game ‘telephone’?” As nearly every hand in the room went skyward, Poole smiled: “How did that game go?” The audience chuckled, and appeared follow his point. If one person tells a group a direction or a goal and the group collaborates there is less chance for project digression. The project is more likely to be what the customer is looking for which is the equivalent of success.

Agile doesn’t only benefit the industry or a company alone, Poole concluded. It also can benefit the individual. He listed these benefits for the agile team member

1. Less cancelled and or shelved work
2. Less pressure or stress over project duration, especially during crunch time as testing is done throughout SDLC
3. More individual ownership and feeling of involvement in a project
4. Increased project success

Poole frequently repeated the phrase, “the simplest thing that could possibly work.” Agile is the simplification of complex tasks, he said, satisfying the customer today and tomorrow, allowing for full software development team collaboration and good returns on investments.

<
Boston SPIN presenter, Damon Poole (on right) speaking with SearchSoftwareQuality.com contributing writer Matt Heusser

Agile expert advises on agile transition snags, PMO problems

Recently, I spoke with Alex Adamopoulos, CEO and founder of emergn about his company’s new agile development transition consultancy program, AgilePMO. In these remarks from our interview, Adamopoulos offers advice on agile development process adoption and his views on agile.

Emergn, is a new company, but Adamopoulos’ experience in the software service field is extensive. He is a 20-year veteran and an active blogger.

What is your agile philosophy?

Adamopoulos: A transformation program. If I think about the guiding principles of an agile engagement, they’re the same fundamental principles of a well-run global company.

What are some common problems within PMOs (Project Management Offices)?

Adamopoulos: Even when I was embedded in the outsourcing community, I thought that large enterprises had a methodical process for why they’d select a vendor, manage a project, etc. I discovered that not only did a lot of them not have them, but the ones that do have them are typically by line of business.

Could you offer a hypothetical example of a company with a PMO problem?

Adamopoulos: A good example would be a top bank, in the top three. Their investment banking side, which drives more than half of the revenue, has a PMO, and that PMO is only operated by three people. It’s fragmented across two geographies. Then, if you go to asset management side, you discover that they have one-person shops or half-person shops. That is common for eight out of 10 of our clients.

Usually, they have no metrics or measurements in place. The metrics that exist are rudimentary project metrics that do not even translate into economic numbers or business value that a CIO can sit with his boss and say, “Here’s why we are making these decisions and how they are affecting our company.”

So, it would make sense for them to explore a way to drive it more efficiently. Right?

Adamopoulos: Clearly the largest problem we see is that there is no single project or program governance in place. There is no methodology for how programs should be governed. There is a lot of waste. We see morale being affected.

What are common snags that occur in transitions to agile?

Adamopoulos: Typically, it becomes a land grab. it is very difficult for some organizations to change their existing behavior and their business psychology. Asking them to collaborate and communicate, and be more dependent upon the business in several areas [is a big deal].

The biggest risk is the psychological impact that agile can have on an organization. Right or wrong, many have already settled into their comfort zones. Agile is a very disruptive methodology, not just at the software level but at the cultural level as well. The larger risks are people asking, “How are you going to impact my job, and why? What does it mean to me in terms of the responsibilities I might have?” There needs to be a lot of coaching in the transitioning people out of their current working mindsets and into something new.

Who are emergn’s target customers?

Adamopoulos: Today, the traditional customer for us is in the application development areas of IT; but we are starting to branch out with the AgilePMO product. Our primary target is the enterprise client, meaning the tier-one enterprise, the $1 billion-plus players. That is where the majority where our business is today. Is it likely that we’ll do things below that? Probably, but it would have to be very specific, because agile enablement reshapes a company’s sourcing strategy. Those are pretty important programs, ones that aren’t taken lightly, and we’ve found that the larger companies are more ready to do those than the smaller players.

The economy has been a help for us as opposed to a hurt; the whole drive of saving money, reorganizing, efficiency has supported our model. So, organizations that have very fragmented sourcing programs are the primary focus for us.

How long do you customers need emergn’s consulting services?

Adamopoulos: I am pretty sensitive to the consulting side. I have been a customer. I don’t believe in having people from the B-team or sit there for one, two years and billing against my company.

Maybe I sound old-fashioned, but we definitely want to drive value. For some companies that may take one year or even half. We are currently doing one large scale agile transfer program for one of the UK’s largest utilities that is a 24-month roadmap, but that is something we defined up front.

British Airways is a great example. We did an entire agile transformation for them. Since they are an airline, they have a gazillion projects going on. We have begun applying a number of initial successes into some points of business. How long they’ll take? I don’t know, but in their case they want to see their entire organization become as agile as possible.