AGL-101 at Gangplank in September, 2010
I’m excited to announce that I’ll be teaching a four-hour workshop “Introduction to Agile and SCRUM“ on Saturday, September 18th. At this no cost event, we’ll participate in exercises and discussion about the Agile Manifesto and the Scrum framework of agile project work. The class will be held at Gangplank HQ in downtown Chandler, Arizona.
Gangplank Academy
Gangplank is a wonderful dream made real by Derek Neighbors, Jade Meskill and other community minded people. It is community centered co-working at no cost, and therefore priceless. Visit their site to learn more about their work. Especially read the Gangplank Manifesto which, in my opinion, drives Agile values into the realm of community building.
One of the efforts of Gangplank is to provide education opportunities for the community. They work to provide the infrastructure for people to share expertise and learn from one another. Regular business and technical “brown bag” sessions happen every week. Other conferences and events are scheduled regularly. All of these events together are create The Gangplank Academy where learning on many subjects and for all ages takes place. This workshop is designated as “AGL-101″ since it is part of the classes of Gangplank Academy.
AGL-101
I am hoping for a great mix of Agile and Scrum knowledge as well as a mix of work focus in this class. Software projects have traditionally been the focus of Scrum application. This is logical since it was created from that industry. However, creators of software product aren’t the only ones who can benefit from Agile values and Scrum. Management, marketing, operations and other facets of the business of production can be improved by application of high interaction and clear communication. I encourage you to invite your peers and people “outside” of software and engineering work to spend this bit of time to learn with us.
RSVP
The event is available on Facebook. If you would, please RSVP on the page. This will help us plan for the proper room and tailor the class appropriately. Comment on the event page too. All the communication we can get helps us help you!
Remember Your Foundation
I had the opportunity to work with Mike Vizdos for a one-day Scrum coaching session. A team in Chandler, Arizona was interested in finding ways to improve, to get outside eyes to help them see what they might be missing. We and the team had a great day. I re-learned something important about working on continuous improvement.
The Team State
This team had grown to more than double their original count over the past year or so. They could see that some things could be improved, some “pain points” needed relief. Some areas we discussed:
- New ways of handling incoming Product Backlog requests, both new development and maintance stories.
- The team structure was also in question. Do they split? If so, how? And why?
- The newer members were integrating well but perhaps more could be done to help them integrate.
- A few team members and many end customers were time zones away. What does that mean for their work and getting to done?
These are more were great questions to be asking themselves. We endeavored to help them with new vision and directions to explore.
Forgetting What’s Good
As we proceeded with the day, reviewing the definition of Scrum and working through their questions, we were focused on what improvements were needed. Pain points were identified, discussed and solution paths planned. This was all going well, with honest conversation all around. And then I was taught by the group’s awesome manager during a late moring break.
He walked beside me down the hall and pointed out that we seemed to be talking a lot about “becoming a high performing team,” as if this team was not already performing very well. The team was already known in the company as very high performing. They delivered on time and with high quality. They were already a great team.
I nearly stopped walking. He was so right! I had already seen that these people were a team, in the best sense of the term. They interacted with respect and intent for the good of the whole. They knew what they were talking about and wanted more from themselves. We had spent so much focus examining the places of difficulty that the things that were right were nearly forgotten!
Remember the Foundation
Foundation by FaceMePLS on Flickr
And focusing on the improvement spots, the pain points, can blind us to the things we are already doing well. As we improve, we build on the foundation of what is already good. So good teams can become great and great teams can always get better because of the excellence they already have!
The next time I’m looking at pain points, I’ll remember to recognize the good work already in place, making the coming improvements possible.
Quick Impressions: Phoenix Agile Burndown
Yesterday morning some people from Rally Software were in town putting on a half-day mini-conference. This event was called the “Phoenix Agile Burndown” and brought together a diverse group of people from the Phoenix area. I just wanted to quickly document some of my impressions of the event. These are in no particular order, I’m just letting the ideas spill out.
- First, I thank Rally for putting on this event here for us. They served a nice breakfast in a nice environment. The cost of the venue combined with the number of staff present was a significant investment in the Phoenix Agile community. Sure, they got exposure and marketing information. They also succeeded in producing and event that was neither pitchy nor preachy.
- A lot of people were there. I estimate at least 60 and there were still name badges left on the table. It was a strong showing of Agile interest here in the area.
- I thank the panelists from three local companies; Pearson, Universal Technical Institute, Infusionsoft. They shared their stories and answered questions. This sort of sharing is important for all of us.
- Many of the questions from people showed a real desire to do things “right” and smart. The struggles are all different but we are not alone in performing them.
- I noted some of the company names on the name badges. The diversity was surprising to me. There were people from retail, utilities, government and heavy industry. Wow!
- I enjoyed meeting different people and sharing some points of interest or question. The community here in Phoenix has some great people!
- Lastly, I thank Chris Conrey from Integrum Technologies for car pooling with me. It was a quick trip and made the better with conversation. And he paid for parking!
I hope to see many of the same people at next Wednesday’s Phoenix Scrum User Group meeting. Should be a great event!
What Does A Product Owner Do, Anyway?
A recent question in the scrumdevelopment group captured my imagination. I had to write a response before sleeping. Most of this post repeats my message in the group. I’ve tried to polish it a bit for posterity.
The Questions
The original post in the group asked some hard questions about the role of the Product Owner. Questions about this role are normal since the original Scrum definition does not go into detail about the day-to-day work of the Product Owner. I think this is intentional as one definition of this role would not fit very many teams and enterprises. Let me paraphrase and condense the questions:
How does the Product Owner build and maintain the Product Backlog? How does he ensure the Sprint Backlog is ready for planning? And, how much time should be spend doing these things?
Study the Role
To understand the power, nature and key importance of the Product Owner role, we should first understand the big picture. Some of the best documentation about the Product Owner role comes Roman Pichler. Look around his site for some great information. In particular, Roman produced a slide set that has helped me many times when explaining the Product Owner role to executives and teams. Read through this set on being an effective Product Owner [PDF] for some great insight.
The process of gathering information about story content; requirements, UI, etc. can vary significantly from company to company and team to team. Scrum does not provide direct instruction about how the Product Backlog should be assembled and maintained. Scrum mostly says that the Product Owner is in charge of the backlog. Lets focus on the main goal for the Product Owner with regard to Sprint Planning:
- The Product Owner needs to have at well defined stories ready at the start of the meeting.
- These need to be in business value priority order.
- There needs to be enough ready to fill at least one Sprint Backlog and maybe a few more, just in case.
- These prepared stories define “What?” is to be created and how everyone will know the creation is complete.
To meet these goals, the Product Owner can use whatever method is needed to collect, document, understand and define the answer to “What?” should be created. Some things the Product Owner might do:
Product Backlog Grooming
In Roman’s writings he emphasizes the idea of a backlog grooming section. There are others also emphasize this idea and I agree with them. Sometime during the Sprint, the Product Owner and all the team developers will spend time fleshing out the stories for the next sprint and maybe a couple more. This allows the team a forward look to help guide the current work and keeps them on the road. Most importantly, it helps the Product Owner understand the costs, risks and benefit of imminent stories.
Stakeholder Communication
The Product Owner will call meetings with the various stakeholders (Marketing, Production, Finance, etc.) to create and refine stories. The Product Owner represents these interests and people to the developers on the Scrum Team. There needs to be communication with these stakeholders often so that their interests are well represented in the stories and hence the end product. These people are not on the Scrum Team (i.e. they are “chickens”), but they are customers, so their input is vastly important.
Team Communication
Besides a formal grooming session, the Product Owner should be available at any time to talk, discuss and meet with the team or individual developers. The best communication method is face-to-face conversation. When such is done between people that regularly spend time together, misunderstanding is much less likely to happen. Specs, diagrams, drawings, etc. are great. Do them asneeded in order to create a great end product. Documents are not the primary means of communication. Face-to-face is the primary means.
Time to Prepare and Define
The amount of detail and work in all this grooming and communication should be biased toward the present and face-to-face communication.
The detail in the Backlog request as far as features, business rules, and the like, should be only as much as needed for customers, Product Owner and team to understand each other. Once they are used to talking and working together, not very much will be needed. Stories in the next sprint or two will have more of this communicated while those further down the Product Backlog will have less. No reason to spend lots of time defining things that are weeks or months away since they will change.
The Product Backlog does not contain detail design. They should have as little design information as possible, for the moment’s need. Maximize the work not done. Remember, the team defines the “How?” of the work, which is the design.
- If the story is in the current sprint, there will be lots of this detail as it is implemented.
- If the story is expected in the next sprint, only as much as needed to be ready for Sprint Planning. Not too much.
- If the story is expected two or more sprints out, only as much as needed to have an understood vocabulary around the story. Not very much at all.
When a Product touches several domains (Marketing, Production, Finance, etc) besides the “product” domain, resist the temptation to do Product Owner by committee. The Product Owner needs to be the one person that the rest of the Scrum Team asks for decisions of priority and completeness of work. The Product Owner may represent many other functional customers but those customers are not members of the team. This is not to say that developers are not allowed to talk to customers, they should. But questions of story definition and priority are for the Product Owner to determine.
The definition of done is defined by the Product Owner, based on customer input. It is part of the answer to the “What?” question. It should be in the story before the Sprint Planning meeting starts. During the Sprint Planning meeting the developers may reveal that the story is to big or to difficult or somehow not possible to accomplish as defined. This is only because the “How?” that is answered by the developers cannot meet the definition of done for some reason. Hopefully this does not happen too often and usually should be resolved in the Product Backlog Grooming and communication with the customers.
Definition of done should also include technical requirements such as “Shall pass unit tests” and “Shall be built on the official build computer before demonstration.” These the developers should define and follow. The Product Owner should understand the importance of high craftsmanship to the end product.
The Product Owner role should not be taken for granted. It is a key role that each team and company must refine in their own way. Keep learning about it all the time. It is one focus that almost always can be improved.
“BDUF Scrum” – Don’t do it!
Finding the Theme
I enjoy helping people with Scrum and Agile. The more I do it, the more I learn and enjoy it. Many of my recent in person and online encounters have had a similar flavor to them. I didn’t put my finger on it until this morning.
In an online exchange people have been discussing the Sprint Burndown Chart. Opinions on it’s usefulness, how it should be used and what it contains vary widely. That’s OK, because every team and situation is different. The point that struck me was one particular comment. This person described how their chart showed burn down of estimated hours for tasks. They adjusted the burndown each day if a task’s estimated hours to done changed, essentially including actual hours into the burndown.
For example, take a task that was originally estimated at two hours. The next day the developer working on the task reports slow progress. The task is not done with four hours already spent. The developer now estimates the task will take ten hours. So the burndown chart data point would be adjusted up by six hours to include the new estimate.
This example shows the desire of this particular team to track actual hours. I suppose they wished to compare them to the original estimates to measure accuracy, though that did not come up. (There are several reasons that I don’t like such a way of doing things, but that is another discussion.)
Other examples along the theme have been
- eight hour planning meetings
- estimating an entire five month long Product Backlog all at once
- two days of wireframing before writing the story
- sprint tracking spreadsheets with more detail than a Gantt chart
So when I was thinking about the burndown of actual hours example and other practices of potential waste, the theme hit me:
Big Design Up Front (BDUF) of Scrum
It seems many people are trying to eliminate BDUF of products, with Scrum implementations that are designed big up front.
- They need to define every possible field that might be needed on a story card before they start using story cards.
- They want to track hours and sub-hour increments on tasks, allocated by a percent of the developers time against other tasks.
- They need backlog spreadsheets with date coded story ID’s, date last edited, comments by department in separate columns and priority votes from each of five stakeholders.
- They make up two page forms for recording the definition of done and how each maps to the appropriate use case record(s).
And they do all this before the first team starts the first sprint. Because, well, they’ll need the data, right?
Maybe they will need such tracking of information someday. Any one of the above might be the right thing to do at some point for a particular team or company or product. Does it make sense to design all this infrustructure up front, not knowing if it’s really needed?
BDUF Practices in Scrum
Finally, after weeks of discussion, meetings, documents and planning, they start the first sprint. And here they are with all these BDUF practices now part of their Scrum processes. Product Owners who have more clerk-work than product innovation-work. Scrum Masters who have to keep asking for actual hours worked. Burndown charts that require an instruction sheet to interpret. A project bogged down by the same stuff that was supposed to be left behind by “going Agile.”
Simple Code, Simple Scrum
The best code is simple, direct and no more complex than it has to be. The best products have a clear function and benefit to their customers. The best information is direct, focused and simply presented. The best Scrum is simple as possible. Just as it is not possible to know all the answers to creating an innovative product before starting development, it is not possible to know all the things needed for an awesome and highly productive Scrum process. Start simple, way simple, with just the basic pieces. Then, retrospective after retrospective, the team and company learns what they need, solves it in a simple way and gets back to the real business of creating a killer product.
Just go! You will learn what you need along the way, faster than you ever imagined!
What I Did At Camp
Desert Code Camp, that is.
Last Saturday, May 15th, was the seventh incarnation of Desert Code Camp. As I briefly announced before, Code Camp is a day of volunteer presenters and attendees bent on learning from each other. I throughly enjoy these events.
Deeper Into Scrum
My first session was “Going Deeper Into Scrum, An Agile Journey” where the goal was not to teach Scrum but to find places where using the framework is difficult for the attendees, and then talk about those places.
The room was full and quiet, too quiet at first. We soon got things going with a definition of the Scrum framework. I drew the flow, cerimonies and artifacts on the board, answering a few questions as we went. I then invited the attendees to write on the sticky notes distributed around the room. They wrote one point or item of difficulty with Scrum on each note. They were invited to the front of the room to place their notes on or near the part of Scrum effected by the note.
The resulting board was awesome!
I then did my best to bring out the issues on the sticky notes, grouping them or pulling them into the discussion as the conversation flowed. Several of the attendees were very helpful with questions and answers as we shared possible corrections to the difficulties. I’m sure we did not address all the notes in the remaining time for our hour. I do hope people learned and shared some gems of help that they can apply to becoming more Agile with Scrum.
Lunch Time
30 minutes was set aside for lunch time. This started directly after my first session. Due to the nature of such a conference, scheduling is done as best the volunteers can with the knowledge they have. In my case, the second session I was teaching immediately followed lunch. By the time I finished excellent after class one-on-one discussions and clean-up, it was time to setup the next class in a different room. Lunch for me would have to wait! (Thank goodness for granola bars!)
Agile Manifesto and Code
I encountered a difficulty with this session because of the classroom layout. My plan was to use slides with the four values and twelve principles of the Agile Manifesto and use the marker board for supporting discussion visuals. The projection screen covered the marker board. I opted to use the slides, since the Agile Manifesto was the text and writing out all of it would kill the flow
The title of the presentation was “The Agile Manifesto – What it means to the code and the coder.” We approached this by defining each value and principle of the manifesto and then discussing what the code would look like and the coder would be doing if they follow the manifesto.
The discussion resulted in many mentions of continuous integration, TDD, paring, refactoring and many other development practices. There were also questions around supporting the manifesto in different business environments such as large vs. small projects. I enjoyed the banter and peer education that was going on.
Community
A large thanks to:
- DeVry University for providing their campus and classrooms for the event.
- Joseph Guadagno, Camp Director, and all the other volunteers I didn’t see but must have been helping.
- The people in the sessions I led. There are many people in the Phoenix area working to improve and learn. They have many questions. They are bravely working on many impediments. They are awesome!
Dynamic Scrum Team Leadership
The most popular post in this blog, by far, is “Scrum Teams Have a Team Lead.” The hits from Google indicate that many people are trying to figure out the role of team leader when applied to Scrum. I have had one comment on the post expressing a negative opinion of not having a single person designated as team lead.
Let’s explore this discussion further in the context of last month’s (April, 2010) Phoenix Scrum User’s Group meeting.
PhxSUG Meeting
We announced the meeting would be a participatory simulation of a Scrum project. About half of the people in attendance had never been to one of our meetings before and many of them were very new to Scrum. We were gratified that some came specifically to experience a Scrum simulation!
We started with a brief discussion of the Scrum framework, with it’s roles, cerimonies and artifacts. With that foundation set, we dove into the activity. The project was five Sprints of the Ball Point Game (PDF)
(Here is a video of the game in action. If you have not tried this game, I highly recommend it. If you watch the video, don’t say too much when you play the game the first time. Don’t give away the secrets too soon!)
All of the meeting attendees are one team. The goal, or “product,” of the team is to transfer as many balls as possible in the two minutes of a Sprint. Between each sprint, the team reviewed performance and planed the next sprint. We had great fun and the team successfully transported all but two of the balls on the last sprint! We then did a bonus sprint with some “cheat codes” from me, the coach, to optimize the process. We succeeded in getting all the balls through in the time allotted!
Debriefing
In our discussion after the game, we found some interesting points:
- Changing even small things between sprints effected performance of the team in bad or good ways.
- High communication was paramount.
- Keeping a rhythm of movement in the whole team was important.
There were several other things learned, one of them was around leadership. As the team was first getting organized for the first sprint, there was some chaos. Lots of people talking, pointing and throwing out ideas. Suddenly one of the participants spoke up and began speaking authoritatively about how the job should be done. The team followed, with some discussion, and the first sprint began. So, suddenly the team had a leader. Not by assignment but by personal energy and willingness to step up.
Dynamic Leadership
During the first planning period between sprints something interesting changed. Another participant pointed out a weakness and suggested a change to cover it. The team followed this suggestion as the previous “lead” blended into the team to make way for a new leader. This passing of leadership continued from sprint to sprint with different individuals teaching the team their ideas about how to improve and others volunteering into key roles. It was natural that the “Team Lead” changed as the needs of the team changed in the quest to improve.
This is dynamic changing of team leadership also happens in a Scrum team. Depending on the goals of a particular sprint, the team may look to the database administrator to lead or the user interface designer. Story to story, sprint to sprint the expertise needed by the “Team Lead” can alter. A team working well allows the currently needed leader to come to the front, and then fall back in favor of a new leader who has the talent or experience to handle the next focus.
When a team has an assigned Team Lead, this leadership adaptation is less likely to happen. Team members will not want to “attack” the assigned lead’s authority by stepping up. The team lead may not want to reveal “weakness” in a knowledge area and so will not allow another team member authority. Once a hierarchy is established, especially when established by higher authorities, it is very hard for those within the structure to alter their expectation of command and allow a better leadership pattern to emerge when needed.
In short, assigning a Team Lead and expecting that person to be appropriate in the role for the entire project is a form of “Big Design Up Front.” There are great Team Leads and managers that know how to foster leadership from team members. I am not denying that such excellence is possible. I am saying that such people are rare and anyone in that position must constantly push and pull against the cultural expectation that they are Lead and therefore must have the answers.
And The Team Shall Lead Themselves
Let the Team be the team lead. Then, the right leader will emerge at the right time as the team naturally strives to accomplish their work. I’ve seen it happen, just as it did the night we were throwing balls around, learning while laughing!
Presenting at Desert Code Camp
This Saturday, May 15th, I will be presenting two sessions at Desert Code Camp.
The first session is scheduled for 11:30 AM: Going Deeper Into Scrum, An Agile Journey. Lunch follows so we have some incentive to end on time!
The next session is right after lunch at 1:00 PM: The Agile Manifesto – What it means to the code and the coder. I promise to make the conversation interesting so we won’t fall into food sleepiness!
Even if you can’t attend my sessions, please come out to the camp to learn and interact with our great technical community. Desert Code Camp is always no cost to everyone. And we will get a free lunch to boot!
Learning the Basics of Agile
Last week an attendee at my Gangplank presentation contacted me with an interesting question. He wanted to learn more about Agile and Scrum. He asked “Where do I start?”
That is a hard question to answer. Not for a lack of information, but because there is so much out there. A great problem!
To answer the question I just sat down and started typing a flow of information. Below is the email I sent to the him, largely unchanged. Eventually I should turn this into a polished document. I hope you find it valuable and get a starting point that works for you!
Learning
First, I have a few Agile learning philosophy tips. I’m sure you have your own learning style and I don’t want to pre-empt that, just give you a frame of mind.
Focus on “academic” (pure) knowledge before you dive into “useful” (applied) knowledge. But, remember that full understanding doesn’t come without application.
There are many things about Agile that are so different in thinking to traditional project and people management that we may want to reject some parts and pieces right off the bat. Suppress this reaction by seeking to first academically understand the concepts and practices. Like you are just taking a class in college that is a general education requirement with no thought of actually applying it after the final exam. But you do need to get an “A” on the final, so learn the topic.
Work through the application stages of knowledge. A concept pulled into Agile from marshal arts is “Shu-Ha-Ri“
- Shu - You learn and do the basics, sometimes without knowing why, because the masters say so.
- Ha - You begin to mix your own experience into the basics, learning where your knowledge can enhance the new knowledge.
- Ri - You are a master and the basics are just part of what you do, are now part of your experience.
Individuals, teams and enterprises go through these stages all the time. The hardest is to accept the Shu stage because we have to unlearn other habits and trust the new knowledge.
It’s about people
As I stated in my presentation, Agile is about people. Yes, eXtreme Programming (XP) is a set of Agile practices that tell developers to pair program and other specific things. Yes, Scrum is a definition of certain meetings, documents etc. that help a team work in a more Agile fashion. But these and other Agile frameworks are designed the way they are because it is the best way for people to communicate and work together. Don’t let the practices become more important than the people.
Agile Manifesto
The definition of “Agile” may be ambiguous to you. It also takes some abuse in companies who claim to be Agile but really only have some of the outward practices without following the true spirit of the movement. To remove this confusion, go to the Agile Manifesto website, read, study and learn the statements and the principles. If you are working to follow these ideals, you are becoming Agile.
Frameworks
The Agile Manifesto was created by smart people who had already developed one development framework or another, realized they had some common foundation and got together to define that foundation. So, one of the best was to start being Agile is by learning and using a framework. The more popular frameworks (sometimes called methodologies) are, in my view:
- Scrum – The one with the most traction and widest use. It is a project management level framework that focuses on the development team. It is simple to understand the basics and get started but that makes it simple to do the motions without being Agile. I started with this framework.
- eXtreme Programming – XP is also well known but not widely implemented. It has some of the same elements of Scrum but emphasizes engineering practices where Scrum does not. Pair programming is the most well known element of XP and probably the reason many reject it. XP and Scrum work very well together.
- Kanban – This one is currently gaining in popularity and originated out of lean manufacturing ideas. It concentrates on work flow, making the flow very visible, thereby exposing bottle necks and waste that should be corrected.
I found Scrum the easiest to personally pick up and to evangelize into the enterprise. Practicing it for three years now, I have much still to learn and am seeking wider Agile knowledge.
Online Resources
The internet is FULL of great resources about Agile. Videos, presentations, blogs and email lists abound. And it is just as good as what you find in books. So don’t be afraid to go searching for things. You will find treasures! Let me give you some starting points.
- http://mountaingoatsoftware.com – This is Mike Cohn’s website. He has written excellent books on Agile like “Agile Estimating and Planning” The site is full of good ideas and, I think, the slides of every presentation he has ever given. A gold mine for learning.
- http://implementingscrum.com – This is Micheal Vizdos’s website, a Certified Scrum Trainer. He uses cartoons to poke fun and knowledge about Scrum. He was my ScrumMaster trainer and still helps me today. His training style is thoughtful and active. If you want to take a course, he’d be a good trainer to pick.
- http://groups.yahoo.com/group/scrumdevelopment/ – The email group for discussions of all things Scrum. All the Agile luminaries, it seems, show up here and answer questions. Troll the archive for great practical advise. If I could never buy another book about Scrum, I’m not worried because this group has all the authors brain’s wired!
- http://video.google.com/videoplay?docid=-7230144396191025011 – This is a video of Ken Schweber speaking a Google about Scrum. This was the first video that hooked me into learning about Agile. It’s worth the time even though Ken is a bit dry.
- If video is a good learning mode for you, check here: http://agileroots2009.confreaks.com/ for videos of all the session of the Agile Roots 2009 conference. Great stuff there!
- http://phxsug.org – This is the Phoenix Scrum Users Group website that I mentioned at the end of my presentation. We have monthly meetings on the 3rd Thrusday of the month. We focus on Scrum but other frameworks come up from time to time.
Books
- Anything by Mike Cohn.
- “Agile Retrospectives: Making Good Teams Great” is awesome for doing this key element of team building practices.
- If you are introducing these practices into a workplace, you need to be a great change agent. The book “Fearless Change” is indispensable knowledge for such an effort.
There are many more great books out there.
Try it!
The best way to learn is by doing. Apply some of the principles and framework pieces as you can. Try a retrospective or make a task board. Use it, inspect how you did, adapt and improve. That’s how it works.
Training
Education is compressed experience and a good class can jump start your improvement efforts. If you don’t feel up to pushing change in you organization, hiring an Agile coach is a good investment.
Ask Questions
Find a community, site or friend. Ask questions of them and yourself. Ask here if you like since I like to answer!
Guiding a Scrum Project Simulation for PhxSUG
I will be guiding the next Phoenix Scrum User Group meeting tomorrow, April 15th. We will be doing a project simulation using Scrum. It will be a fun opportunity to experience Scrum in action! Discussions will help both novices and experienced Agile practitioners alike.
Meeting details are available at the PhxSUG website, where you can sign up for this event and to hear about other group meetings.
I’d love to meet you there!
