Tag Archives: agile

AgileExams.com Controversy Resolved…Sort Of

Posted on
2

Well it turns out the “controversy” about AgileExams turned out to be the biggest of misunderstandings.

The Testimonials Were Authentic: Several of AgileExams customers contacted me and revealed the root cause of this confusion is the fussiness of PMI.org’s online certification registry:

  • The name on the testimonial may not be the same format as the name in the registry (e.g. Joel Bancroft-Conners explains you can find his name by searching ‘Bancroft’, but not ‘Conners’)
  • There are occasional delays from passing when a candidate passes the exam, until they are listed in the system.
  • Most of all, candidates may choose not to be listed in the registry (which beguiles me, since the whole point of a certification is to assert to people that you’ve accomplished a structured learning program)

However, there are some bitter hard feelings left over. Joel posts an excellent analysis of the situation: The issue is not the issue. Apparently Yes, the testimonials may be authentic, but that didn’t stop the controversy from happening. In any crisis management situation,  (e.g. Joel cites The Toyota Prius), the response to the crisis often matters more than the core problem.

Privacy is not an effective crisis management response for public issues: In response to the issue, the owner of AgileExams has asserted his privacy by removing his LinkedIn profile from the internet, and personally asking me to refrain from using his name, which I have done. Yes, he has the right to his privacy, but only if he choses to remain in the private. Once you go out into the public with a product, you offer some of your privacy in exchange. Some examples from last night’s Republican debate show the point. Newt Gingrich blasted the press for highlighting the personal nature of his marriage. He made the point that some things are personal, and not related to public life. But then Newt promptly forgot his got high-and-mighty position when he questioned Mitt Romney about not releasing his tax returns. It turns out if you run for public office, you lose some of that right to privacy. Likewise, if you release a product online, then you have to expect the public scrutiny of 2 billion internet users.

Personally, I’m glad the service was exonerated. It further validates the efforts of the 515 project managers who earned the certification. Also, I believe the service made a substantive contribution to the community. So, for what it’s worth, I’m sorry that AgileExams had the misfortune to endure this controversy, but alas sometimes it is the price one has to pay to be successful.

AgileExams.com Embroiled In Controversy

Posted on
10

Today, the Agile journalistic blog AgileScout.com posted a discovery that testimonials for the PMI-ACP exam prep service, AgileExams.com, may be engaging in some false advertising.

Controversy 1: Several of the testimonials come from people NOT listed as PMI-ACP certificants. PMI offers a public registry on its website, which allows employers to verify whether someone has the PMI certification they claim to have. Curiously, several of the customers quoted on AgileExams.com are NOT listed as certification holders. For example, the site quotes Jonathan Daly saying “…your site made the real exam a breeze”, but Daly is not listed in the PMI-ACP registry. Granted, PMI offers certificants the option of NOT being listed in the registry, for privacy reasons. But granting permission to be quoted, and then not granting PMI to list you in the registry seems odd.

Controversy 2: The advertised customer success rate is a bit naive. The post also reveals that AgileExams.com asserts that of their customers who actually took the the PMI-ACP exam, a full 97% passed. Unfortunately, PMI provides no way to tabulate failing candidates. Instead, AgileExams.com offered an open call for its customer to self-report whether they passed or failed. Not surprisingly, only 3% of his survey respondents admitted to failing the exam. As a trainer myself, I have received 0% of my own customers saying they failed the exam. Yet, I’m not naive enough to assume that nobody failed. I can only know for sure that nobody is willing to admit to their trainer that they failed.

Controversy 3: The site offers little in the way of Agile reputation . The site owner, [name omitted], is a relative unknown in the agile space, and some skeptics want some information as to who is involved in the product’s creation, and how it was put together. However, other people have commented directly on the blog post that they care less about this, and more data about the product’s effectiveness.

Summary: In the end, what looks like a juicy controversy may just be some circumstantial misunderstandings. Here’s how AgileExams.com can clear all this up:

  • Update the website with testimonials from candidates who are listed in the PMI-ACP registry.
  • Update the website to focus on the LinkedIn testimonials: http://www.agileexams.com/linkedin-group-testimonials/
  • The site owner can post an open letter on his website explaining who worked on the product (including the associated AgileBOK.org), whether they bring any agile expertise to bear, and the methodology they use for building the site.

In my opinion, some simple website edits can quell this controversy, and also build the product’s reputation at the same time.

What about you? What do you think of the website’s product, and the claims it makes about the product?

Yes, I Am Writing a PMI-ACP Exam Book

Posted on
2

PMI-ACP book. Agile experts tell you the agile way to earn PMI's new agile certification

I’m excited to announce that I’m writing a book to help agile practitioners earn the new PMI-ACP agile certification. 4 years ago, I started by helping PMI launch the Agile Community of Practice. Then 2 years ago, I worked with some great experts on building the certification program. Now, this book is the next step in my journey to encourage project leaders to grow in their understanding of Agile project management.

Also, this book will benefit from a lot of talent. I’m writing the book with my good friend Hiren Doshi. We’ve engaged visual communication experts Take-Action.com to illustrate the book, and have brought on some good editors.

Our target is to complete the book by the start of 2012, but anyone who’s written a book knows there are challenges to that. For example, people are beginning to post their initial feedback on the exam, which may cause a lot of last minute changes to what information is most helpful.

Also, You can go to the official website and download a free sample chapter to see what we’re trying to achieve.

So here is my question: What would you like to see in a PMI-ACP exam book?

Reflections After a Year of Agile Coaching in India

Posted on
15

Agile Coaching India

I started working in India full-time in August of 2010. As an American, I had a suitcase full of expectations and assumptions. After a year of working with Indian IT professionals side-by-side, it’s time for a few reflections and observations.

Scrum in India is HOT. Some 18 Months ago, there was only one reliable vendor offering Certified ScrumMaster (CSM) training in all of South Asia (Pete Deemer of GoodAgile.com), and he was based in Singapore. Now, there are three Certified Scrum Trainers based in Bangalore (Pete, myself, and Vibhu Srinavasan of Solutions IQ), and a Certified Scrum Coach in Hyderabad (Madhur Kathuria). Added to that mix is a spike in agile events, such as the quarterly Scrum Bangalore, the mulit-city Agile Tour, and the upcoming Agile India 2011.

India’s Talent is a Strength. There is an obsession in this country with education. Driving from my home to the airport, I see two to three DOZEN billboard adds for bachelors and masters programs. The kids that score highest on standardized scholastic exams are featured in front-page newspaper articles. It then extends into the professional world. An amazing 2010 book called The India Way highlights the dramatic difference between American and India with regards to talent. In America, companies find talent, but Indian companies develop talent. When I joined large companies like Bell Atlantic or Lockheed Martin as a young engineer, my orientation took 2-3 days. Here in India a new hire can spend up to 6 weeks in skills development training. But it doesn’t end there. Most large firms have a “learning & development” organization that hosts dozens of training programs at a time, which employees are required to take as part of their annual appraisal process. What that means is engineers in India are hungry. They are eager to learn and try new things if you let them. By far and away, Indian teams leave my agile training even more energized and motivated than their US counterparts.

Infosys boasts the world's largest employee training center

India’s Talent is an Impediment. All that positive energy around engineering talent comes to screeching halt after a few years of professional experience. Over the last 30 years or so, the West has fostered the concept of the technical career track. For example, at Marriott headquarters in Washington DC, I met a really smart yet simple man who retired in 2009 as a life-long Cobol programmer with a happy family. In India however, that would be considered a wasted life. If you are still programming after 5 years of experience then something is wrong with you. You should have been promoted to the higher-paying and higher-prestigious management role, where you could then provide a better life for your children. I had one test manager tell me to my face, “Taking the role of an agile team leader is a demotion, and my career won’t be able to survive that.” Yes, there is talk of a technical career track in India, but it usually means getting promoted as an architect or a professor who has long since stopped programming and now tells other engineers what to do. Also, all that free technical training is a set of golden handcuffs. As a provider of IT certification training, I hear many questions along the lines of “Why should I invest in my own career advancement, when every company I’m interviewing is promising me similar training at no personal cost?” This all adds up to a dramatic gap between mid-level engineers and strong senior engineers like Robert Martin describes as the crux of software craftsmanship. Those engineers do exist, but you should expect that your Indian agile teams consist of many motivated, but relatively junior engineers.

Global IT infrastructure is an impediment. Without a doubt the largest shock I have experienced is the atrocious support that multi-national software teams receive from IT infrastructure departments.

  • Some of it is simply multi-national business. The parent company in the West has its network domain, and the subsidiary in India has its network domain. Because they are two different companies, the workstations and servers often are not directly accessible to each other without jumping through VPNs, firewalls, and removing servers.
  • Some of it is cost pressure. One of my clients does not even issue proper workstations to its engineers, but instead has them remote into Virtual Development Instances. Shared virtual development workstations will save a few thousand dollars on hardware costs, but it yields competition for system resources, and more network latency on my coding and testing.
  • Some of it is just mean. Another client of mine is doing iOS development, but the IT department only supports Windows PCs on the network. One would think simply to do a manual sync of the source code to their macs, using a USB pen drive. BUT, the USB ports on their company-issued PCs are disabled “for security reasons”. I won’t say the hack these guys used to get their work done, but let me tell you it would make any sysadmin shiver in his bones.

Regardless of the reasons, it all adds up to wasted productivity. I estimate that Network latency + system resource latency + manually doing what a computer should do = 30-40% loss of engineering productivity. I blame the Fortune 500 CIO for this. His executive mandate is to cut costs, without regard to the ten times great loss of productivity and employee satisfaction. This means if you are dealing with distributed teams, expect IT infrastructure to be your number one issue. Worse than the time zone. Worse than the culture differences.

Everyone is doing it. Another misperception in the west is that only a small syndicate of evil CIOs have shipped jobs overseas. Here in Bangalore, a casual drive down along outer-ring road road will reveal the following firms: IBM, Perot Systems, CapGemini, Tesco, SAP, GE Healthcare, Oracle, Cisco, Intel, Accenture, and Dell. And that’s just eastern Bangalore. Other cities in India feature firms ranging from John Deere (Pune) to Microsoft (Hyderabad). After trading stories with my colleagues, I have learned that a surprising plurality of Agile coaches have made at least one visit to India in their career.

Even India is doing it. One American colleague asked me over dinner, “Jesse how do you respond to the challenge that, as a business agility coach in India, you are an accomplice to India’s sucking technology jobs away from America?” I was stumped by the question at the time, but the more I see of global IT, the more complicated the picture has become. For example, all the top Indian outsourcers have a significant footprint in the US (Wipro has 14 offices across the US), and one of them is even headquartered in the New Jersey (Cognizant). The biggest shock came way back in 2004 when India’s largest Telecom, Bharti Airtel, “reverse outsourced” its IT to IBM for $700 million. But now, it’s getting even more complicated: Last year, Airtel hired the New York based IT giant again, this time to support the Telecom’s expansion into 16 African countries. During the 2012 election season, we will hear a lot of politicians calling for a ban on outsourcing. But doing so may actually have a domino effect on current jobs in their own districts.

I’ve got other observations lingering around in my brain, but these are the first I wanted to share. What about you? What differences have you seen between the Western and Eastern approach to IT work?

Pitfalls of Agile Project Management

Posted on
11

People often ask me whether Agile PM is a good fit for their project. In general, I tell them that delivering more value to your sponsors, sooner, with higher quality is always a good thing. However, pursuing those goals is not devoid of risk. I warn people about three key pitfalls when choosing to “go agile”.

Overhead
Agile PM is not for free. Many project managers assume that agile means no planning and no documentation. Imagine their shock when they find that a standard agile framework employs no less that 4 levels of planning (daily, iteration, release, project) and a full suite of artifacts called backlogs (product, iteration, impediment, risk). Complex projects need a certain amount of coordination to be successful, and an Agile approach is one that merely seeks the right balance of the right amount of process to manage those projects. However, if your project is instead a small, simple, low-risk affair, then the overhead may not be worth it. A certain investment of time and resources are required to implement the discipline and rigor that Agile frameworks require. Before you go Agile, be sure your project is sufficiently risky and complex to merit that investment.

Truth
Agile project management is not a silver bullet; it is a magic mirror. It does not fix your problems, but rather reveals your problems in such painful clarity that you are compelled to actually address them. When the complexities of a 1-year project are compressed down to a 1-month increment, there is no longer anywhere to hide. For example, if you have a talent problem, iteration deadlines will be missed consistently until you build more skills. If have a negative team culture, forcing people to work together across silos will cause more pain until you attack team dynamics directly. If you have a track record of generating defects, you will have more embarrassing customer demos until you implement tighter quality practices. Beware. When so many problems come to the surface, the PM will often get the blame for introducing this Agile craziness. Agile PM is designed to help project managers tell the truth with empirical data. As it turns out, people are often not able to handle the truth, and will instead shoot the messenger. Before you go Agile, be sure you are prepared to handle the truth when it is revealed.

Change
Those familiar with the WYSIWYG acronym (“what you see is what you get”) will enjoy another. WILIWIK: “What I like is what I know”. Many people around us simply don’t want change. The pain of the known seems safer than the risk of the unknown. Methodology expert Alistair Cockburn has identified this as a human failure mode in project management. Anxiety will grip project managers when they learn the chosen agile frameworks does not explicitly highlight the project manager role. Annoyance will come from isolated ivory tower engineers who must now attend meetings with those pesky sponsors who pay our salaries. Protests will arise from requirements analysts who must now prepare feature specifications every month, rather than only once per year. Change is hard. Before you go Agile, be sure you understand the dynamics of the changes you are about to introduce.

Agile is not for everyone. Its overhead is best saved for high-risk complex projects; its truth-telling requires courage; it’s differences demand a disciplined approach to change. Understanding these pitfalls can make the difference between Agile failure or Agile success.

The Quality Iceberg Game

Posted on
6

This is really 2 posts in one. I have an observation to share, and then a team exercise based on that observation.

QualityIceberg.jpg

Technical Risk Runs Deep

The observation comes from scrum expert Colin Bird. Colin is one of the most gifted agile architects in the world, and often rants about the mismatch between industry standard quality practices and true technical risk. His point is this: “why do we spend so much money on testing through the GUI, when 90% of the risk is underneath the GUI?”.  It’s an intriguing question.

A standard application can be divided into three sections: the unit or module level, the integration level where those modules interact, and the GUI that exposes the behavior of all that integration. Where do most of the defects come from? Below the GUI. But consider that large tech companies hire dozens even hundreds of testers, clicking through an application, to be the primary counter measure for technical risk. Yes defects are found, but when when you consider the salaries of those manual testers, the licensing fees for those automated GUI testing suites, and the performance cost of going through all the tiers…the cost of finding those defects can be staggering.

Instead, agile engineers know to invest in low-level quality techniques like unit-tests (aka TDD), real-time peer reviews (aka pair programming), code consistency (coding standards), proper design patterns (refactoring). Low-level quality techniques also address the integration of stand-along components or services. These could include design-by-contract tests, or automated acceptance tests (using FitNesse or Selenium).

Let The Team Decide Its Risk Management

As a team lead, agile coach, or ScrumMaster, how do you hammer home this point? As an Innovation Games® Trained Facilitator, I am a big fan of collaboration games. During a session with a team at Cisco here in India, I adapted a game call Prune-The-Product Tree. The intent was to have the team explore technical practices on their project, in a collaborative fashion. Here’s the instructions:

1. Draw a triangle, divided into 3 tiers (UI, Integration, Unit).

2. Tell the team to think of every quality technique they can think of

3. For each technique, post a sticky note onto the area it addresses

4. Here’s the interesting part. After 5-10 minutes of listing all the techniques, ask this question: “Will all these techniques fit into a single iteration?”. The team all answers in unison, “NO!”

5. Then tell them to choose which quality techniques will fit in the current sprint, while also remove the most technical risk and achieving the highest quality.

QualityIcebergGame.jpg

 

This final step is where the gold is mined. Team members have to negotiate which practices best address the quality iceberg. There will be strong opinions. The testers will prefer the GUI-driven techniques, because that is generally how they are trained. The agile types will ask for all the code-level techniques, even though they’re the only ones trained to do them. To help get to some reasonable consensus, you may announce some caveats (“Don’t worry about lack of training or tools for certain techniques. Pick the ones you think will work best, and we’ll get you the support you need.”

Then you take a step back and declare this iceberg is our “Definition of Done” for the next iteration. If there are problems, we can discuss adjustments during the next retrospective.

CollaborativeDefinitionOfDone.jpg

Just Enough, Just In Time, and Sometimes Just Because

Posted on
13

This post currently appears as the latest installment of my recurring “The Agile Project Manager” column in the January issue of PM Network magazine. PMI members can view the original printing of the column here: http://www.pmnetwork-digital.com/pmnetwork/201101?folio=17

“How much up-front planning should we do? How many people should we hire? How many meetings, documents and procedures do we need?”

No matter what field or what project, we all face the “how much?” questions over and over. To avoid getting bogged down, project managers should heed three golden rules: Just Enough, Just in Time and Just Because. I first heard these from Mike Griffiths, PMP, one of the earliest council members of the PMI Agile Community of Practice, when we were struggling with a lengthy document. After much debate, Mike interrupted with a seminal insight in agile efficiency: “When it comes to documents, I coach my teams to generate just enough, just in time and occasionally just because. I think this document fits the last category. Our client has asked us for this document, and even if we consider it excessive, the project will simply never get launched unless we use it.”

Let’s take a closer look at these three tenets of agile productivity:
Just Enough
GOLDEN RULE NUMBER 1: Just Enough. Only do enough prep or support work to achieve the primary goal of delivering business value. The problem is that we so easily intertwine this work with the bottom-line deliverable we’re paid to generate. With that confusion comes the temptation to do more prep and support work than is necessary or required.

Yes, we need a project roadmap, but rather than spend time building a yearlong plan down to the hourly resource requirements, we’re going to provide just enough detail to communicate a vision to stakeholders.
Yes, our IT staff needs some technical direction, but rather than waiting to architect every layer of every interface of every system up front, we’re going to provide just enough direction to get started.
Yes, we need to pass the certification and accreditation audit. But rather than defensively launching an avalanche of paperwork, we’re going to collaborate with the auditors to deliver just enough documentation to satisfy them.

Just In Time
GOLDEN RULE NUMBER 2: Just in Time. You could be crafting lightweight documents, lightweight architecture and lightweight processes—and still be doing all that lightweight work way too prematurely. Of course we could need that architecture component, but let’s invest the time to implement it only when we know for sure we’ll need it.

Of course we’ll need a detailed action plan for next year’s project phase, but let’s devote time to crafting that detailed plan when we get to that phase.
Of course we’ll need to generate some documentation, but let’s wait until we get the documentation requirements before we waste our time on unnecessary write-ups.

Just Because
GOLDEN RULE NUMBER 3: Just Because. This is the constraint that keeps us grounded in reality. I know the 40-page template violates “just enough documentation,” but we’re going to use it, just because we won’t get sign-off without it.

I know forecasting the full project cost up-front violates “just-in-time planning,” but we’re going to do it, just because we won’t get funding without it.
I know triple-entering our hours into the timesheet system violates “just enough administration,” but we’re going to do it anyway, just because we won’t get paid if we don’t.

The next time you’re faced with a dilemma over “how much” of something you should do, rely on these three rules to generate an agile response.

Agile Co-Founder Issues a Call to Action: Stop Bickering

Posted on
10

oath-of-non-allegiance-badge-large.png

As a project manager, a member of the PMI, and an Agile Project Management practitioner, I get yelled at a lot. PMP-certified project managers call me irresponsible for advocating the Agile approach to projects, and Agile practitioners call me a turncoat for collaborating with members of the PMI. It’s understandable that people who are used to one way of doing work are skeptical of another way of doing work. I get it. But does get tiresome. Last year, a fellow Scrum trainer called me a placator, akin to Neville Chamberlain, and it was not meant in a lighthearted manner. However, I am not the only recipient of that kind of vitriol. The Agile PM community is riddled with factions and in-fighting. In the pursuit of truth, many of our so-called thought leaders have taken rather inflexible positions of “No matter what you say, I’m right and you’re wrong.”

Well, today I’m in a collaboration session today with technology management thought leader Alistair Cockburn. In our chat today, he introduced me to his latest initiative, The Oath of Non-Allegiance. It is a web page that challenges Agile practitioners to formally sign and ratify the following:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

Finally! Someone has taken a stand to hold these Agile thought leaders accountable to the core value of “Collaboration” they all advocate. As a co-founder of the Agile Project Management movement, Alistair has been dragged into many of these philosophical feuds. I’ve always appreciated him for advocating the Scrum alongside his own Crystal methods. It’s a strong statement to say your thing is good, and this other thing is also as good, and you’re willing to teach them both.

QUESTION: What do you think of these Agile factions? Do you think this Oath will help the issue?

 

The 19 Keys to Successful Agile Projects

Posted on
6

nineteen.png

This past Sunday saw the kickoff of the Scrum Bangalore User Group in Bangalore, India (more on that later). At the meeting, Scrum expert Pete Deemer gave us these 19 nuggets of wisdom from his many years as an Agile coach for organizations across the world.

  1. Do it for the right reasons: Like Harry Potter, when evil wizards use good magic for evil purposes, they get destroyed.
  2. Start with teams that want to try it: It’s counter-intiutive, but don’t force a pilot effort onto resistors. Have the teams pick themselves. Then, set their expectations: “Are you sure you want to try it? It’s really dangerous. You can try it, but only for 1 sprint”.
  3. Set realistic expectations for Scrum: Don’t go in saying, ”Scrum will save our disaster project”. Force a project restart & give the team 3-5 sprints of breathing room. That’s how long it takes to get to all cylinders/cruise control.
  4. Call it a pilot program for as long as possible: People assume a pilot is messy, and nor will a pilot threaten their long term career.
  5. Change is scary to many people: Humans aspire, in an unfriendly world, to protect ourselves with some stability and predictability. Introduce your changes gently: “Scrum may not be right for us, but we won’t know until we’v tried it. So let’s do it all-in, correctly, for 1 sprint. Did we see any benefit? If so, let’s do it one more sprint. It’s one way of working. It’s not the final way of working, but it might help us get a little bit better”
  6. Patience is a virtue: - Start with 1 team and grow gradually from there. You don’t want 20 teams all struggling with the same issue we’ve yet to figure out.  Instead, it’s better to have one trailblazer fix that issue so others don’t have to.
  7. Find the Scrum middle path: In some ways, my job is a purist advocating the dramatic change, speaking hard truth, but then encouraging teams to tailor the practices to their situation. Be careful though; many organizations respond to the pain of change by diluting the change.
  8. Scrum is hard: it surfaces your nasty, accumulated junk. If you’re not prepared to deal with the issues that Scrum reveals, then it will be very hard to continue.
  9. Get experienced help: Consultants are not afraid of getting sacked, nor do they have a departmental agenda.

pete-deemer-scrum-bangalore.png

  1. Get high quality training: Often, adoption failures are associated with the initial training provided by someone who was told to read a book over the weekend. Better to send 1 person to really good training, than to send 20 people to bad training.
  2. Your enemy is your friend: Spend the most time with the people that like Scrum the least. Put your chief resistors on the Scrum steering committee. If they’re not engaged, they’ll miss how it works, and feel marginalized.  Also, those resistors will help you understand the key roadblocks to successful adoption.
  3. Be prepared to use Guerilla tactics: Namely, if management won’t solve your problems, sometimes you solve them yourself. One example: get your own screwdriver and change the cubicles over the weekend.
  4. Find your guardian angels: You need senior managers who “get it”. When you need to bend a corporate rule or special budget funding, your guardian angel. Indeed, many executives are eager to try an Agile approach, because they’ve worked on so many project train wrecks over the years.
  5. Make good information more accessible than bad information: There is a ton of bad information on the internet about what an Agile approach is or isn’t. Establish a steady flow of good information with email updates, brown-gab lunches, staff meeting talks.
  6. Measure the results early and often: Publicize the good and the bad results. Have both business and technical metrics. Use surveys to measure both the customer’s satisfaction and the team’s satisfaction.
  7. The urge to tinker is great: To illustrate the difference between tailoring and compromise, Pete described a game of “CricketBut”. We play Cricket, but instead of a pitch, we’ll use my living room. Instead of a wicket, we’ll use my dog. Instead of a ball, we’ll use a brick. Instead of a bat, we’ll use my head. After a few overs, you will have bloodshed, just like at the office.
  8. Choose your tools carefully: Don’t ask “which tool should we use”, but ask “What problem are we trying to solve that makes us think we need some software tool?”
  9. Don’t stop with just the members of the Scrum team: Scrum is an organization framework. Often a team can be successful on a localized level, but the organization is stuck in bad habits and the success is not fully realized. You as a team might be able to deliver results, but if it doesn’t get out to the end customer, who cares?
  10. Scrum will always be messy: The Agile movement is fundamentally about people and what they do. If people aren’t perfect, then our projects will never be perfect either. You will always have conflict, mistakes, and challenges. Simply ask yourself, “is it better than it was last month”.

It was a lively talk, that yielded some good points. Pete has a witty energy about him that made the talk even more enjoyable.

QUESTION: what have you seen to be the keys to successful Agile projects?

Agile Project Managers in Illinois this Tuesday Night

Posted on
Reply

illinois regional agile user group

This coming Tuesday night, April 27th, I’ll be presenting at the Illinois Regional Agile Users Group in Bloomington, Illinois. I will be continuing my series on “What is an Agile Project Manager Anyway?”, where we deep dive on the role of an Agile Project Manager on both traditional and agile projects.

I’m really excited about this crowd. From what I hear, IRAUG is the hottest new Agile networking group in the country. If you’re in the area this week, I’d love to have you come check it out and join the conversation.

  • Topic: “What is an Agile Project Manager Anyway?”
  • Date: This Tuesday night, April 27th @ 6:00PM
  • Venue: Holiday Inn Express, 1031 Wylie Drive, Bloomington IL 61701
  • Details: http://www.meetup.com/IRAUG-ORG